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Pralaca 


The  authors  and  their  colleagues  have  been  experimenting  with  a collection  of  Ideas  about 
programming  languages  for  several  years.  Our  goals  included  determining  the  extent  to  which  language 
could  support  contemporary  programming  methodology,  could  aid  in  the  construction  of  verifiable 
programs,  and,  at  the  same  time,  could  be  a completely  practical  programming  tool. 

In  the  context  of  that  exploratory  spirit  it  seemed  inappropriate  to  rigidly  bind  decisions  about  the 
details  of  the  language.  Hence,  although  our  explorations  were  carried  out  in  a relatively  uniform 
notation  and  published  under  the  name  "Alphard",  there  really  never  was  an  Alphard  language.  The 
astute  reader  of  our  previous  publications  will  have  noted,  and  probably  will  have  been  frustrated  by, 
the  fact  that  we  felt  completely  free  to  change  the  notation  from  paper  to  paper  as  the  needs  of  our 
exploration  seemed  to  warrant. 

With  this  document  we  are  breaking  with  our  previous  strategy.  We  are  now  defining  a specific 
language  which  we  expect  to  serve  as  the  basis  of  our  further  research.  In  the  future  we  do  not 
intend  to  alter  this  language  in  the  same  free  manner  as  we  have  In  the  past.  There  are  two  reasons 
for  this  shift  in  strategy:  First,  although  we  didn't  admit  it,  much  of  the  language  was  frozen  In  our 
heads,  and  the  minor  differences  that  appeared  in  published  examples  only  served  to  confuse  our 
readers.  Second,  and  far  more  importantly,  we  believe  that  the  premises  on  which  all  the  "data 
abstraction"  languages  are  based  are  untested  in  practice.  We  feel  the  need  to  gain  experience 
before  we  can  proceed  with  any  confidence  to  tackle  the  next  set  of  exploratory  questions.  To  gain 
that  experience  we  need  to  freeze,  and  to  implement,  at  least  some  portion  of  the  language  — and  that 
is  what  we  are  now  doing. 

Since  we  expect  to  work  in  the  context  of  the  language  defined  here  for  some  time  to  come,  the 
language  Is  extremely  conservative.  Our  past  experience  has  been  that  simultaneously  achieving 
verifiability  and  efficiency  Is  possible  ~ but  delicate.  Hence  we  have  chosen  to  Include  only  features 
whose  implications  we  fully  understand.  For  example,  we  have  omitted  features  dealing  with 
concurrency,  exceptional-condition  handling,  and  so  on.  We  fully  appreciate  that  these  features  will  be 
needed  in  a "production"  version  of  Alphard;  they  are  omitted  here  because  they  are  still  the  subject 
of  our  research. 


The  present  version  of  this  report  carries  the  word  "Preliminary"  in  Its  title;  we  hope  to  promptly 
circulate  a second  version  of  the  report  from  which  this  word  has  been  elided.  Our  purpose  in 
circulating  this  first  version  is  to  solicit  comment.  We  will  deeply  appreciate  any  and  all  critiques  of 


both  thn  * language  and  its  presentation.  Such  comments  should  be 
Computer  Science  Department,  Carnegle-Mellon  University,  Pittsburgh,  Pa.  1521 3. 


i 


I 


n n 


I 


An  Inform ml  Ooflnitloo  of  AlpAord 


I 


1. 

Introduction 

2 

1.1. 

Unusual  Aspects  of  the  Language 

3 

1.2. 

Style  and  Conventions  of  the  Report 

5 

2. 

Fundamental  Concepts 

7 

2.1. 

Objects,  Addresses,  and  Values 

7 

2.2. 

Type  and  Type  Descriptions 

8 

2.3. 

Binding 

10 

2.4. 

Type  Matching 

11 

3. 

Basic  Lexical  Structure 

14 

3.1. 

Symbols 

14 

3.2. 

Comments 

14 

3.3. 

Identifiers 

15 

3.4. 

Special  Rewrite  Rules 

15 

3.5. 

Special  literals 

17 

4. 

Program  Structure,  Expressions  and  Statements 

19 

4.1. 

Program  Structure.  Blocks 

19 

4.2. 

Expressions  and  Statements 

19 

4.3. 

Invocations 

20 

4.4. 

Conditional  Expressions 

22 

4.5. 

Value  Expression 

23 

4.5. 

With  Expressions 

23 

4.7. 

First  Expression 

24 

4.5. 

Loop  Statements 

25 

4.9. 

Exit  Statements 

25 

4.10. 

AMI  Statement 

26 

4.11. 

Inner  block 

26 

4.12. 

Assert  Statement 

26 

5. 

Declarations 

28 

5.1. 

Scope  of  Declarations 

28 

5.2. 

Auxiliary  Declarations 

26 

5.3. 

Remote  Definitions 

29 

5.4. 

Label  Declarations 

29 

5.5. 

Object  Declarations 

29 

5.6. 

Evaluation  of  Type  Descriptions 

30 

5.7. 

Formal  Parameters 

32 

6.5. 

Routine  Declarations 

33 

5.9. 

Form  Declarations 

35 

5.10. 

Abbreviations 

36 

6.11. 

Generators 

37 

6.12. 

Assumptions 

39 

An  Informal  Definition  of  Aiphard 


Apx  A:  Collected  Syntax 

Apx  B:  Standard  Prelude 

B.l.  Primitive  Prelude 

B.2.  Standard  Prelude 

B. 3.  Implementation  Prelude 

Apx  C:  Special  Identifier  Assumptions 

C. l.  Generator  routines 

C.2.  Extensible  routines 

Apx  O:  A Complete  Example 


Apx  E:  Proof  Rules 


2 


An  Informal  Definition  of  Alphard 


Chapter  1 
Introduction 


The  Alphard  language  has  been  designed  to  meet  several  objectives  simultaneously: 


To  support  contemporary  programming  methodology,  and  to  encourage  the  development  of 
understandable  and  modifiable  programs.  Specifically,  we  wish  to  make  the  abstractions 
used  during  the  construction  of  a program  explicit  in  the  resulting  program  text. 

To  permit  formal  specification  of  properties  of  a program,  and  to  permit  practical  verification 
(proof)  that  the  program  satisfies  these  specifications. 

To  permit  the  programmer  to  control  certain  decisions  that  have  traditionally  been  preempted  by 
the  language  implementation  (e.g.,  the  representation  of  data  structures  and  method  of 
storage  allocation). 

To  permit  the  Alphard  compiler  to  generate  compact,  efficient  code.  With  the  aid  of  an 
optimizing  compiler,  we  oxpect  to  produce  better  code  than  is  typically  produced  by 
assembly  language  programmers. 


In  setting  these  objectives,  our  principal  concern  is  with  high  quality,  r«e/  programs  — those  which  are 
used  extensively  and  are  of  significant  size  and  complexity.  Many  of  these  programs  arise  in  the  area 
which  has  been  called  "systems":  compilers,  operating  systems,  and  the  like;  such  applications  are 
representative  of  our  concerns  although  they  are  not  our  exclusive  focus.  Our  intended  user 
community  consists  of  relatively  experienced  professionals  rather  than  casual  or  student  programmers. 


The  designers  of  a programming  language  generally  make  a number  of  philosophical  decisions  that 
have  manifold  effects  on  the  product  of  their  effort.  We,  for  example,  believe  that  "power"  or 
"expressiveness"  is  best  achieved  through  mechanisms  which  permit  the  programmer  to  synthesize 
more  complex  facilities  out  of  relatively  simpler  ones.  Thus  the  composition,  or  structuring 
mechanisms  play  the  central  role  in  Alphard;  by  contrast,  for  example,  the  collection  of  primitive  data 
types  is  small.  The  philosophical  justifications  for  this  decision  are:  (1)  all  of  the  familiar  data  types 
can  be  built  from  Alphard's  primitives,  (2)  the  basic  language  is  much  simpler  without  a large  collection 
of  data  types,  and  (3)  in  making  the  composition  mechanism  strong  enough  to  define  the  familiar  data 
types,  we  have  also  made  it  strong  enough  to  define  many  more  problem-specific  ones. 

Perhaps  nowhere  are  the  language  designers'  philosophies  more  evident  than  in  those  decisions 
relating  to  the  tradeoffs  between  expressiveness,  safety,  and  efficiency.  Alphard.  like  all  languages, 
strives  for  a balance  between  these,  but  our  notion  of  balance  is  colored  by  the  intended  application 
area(s)  and  user  profiles.  For  these  applications  the  long  term  costs  of  maintaining  and  running 
programs  far  outweigh  their  initial  development  costs.  Thus  we  have  tilted  the  balance  in  favor  of 
those  language  attributes  which  contribute  to  efficiency  and  maintainability,  possibly  at  the  expense  of 
those  which  facilitate  rapid  program  construction. 


We  have,  for  example,  not  emphasized  "expressiveness"  in  the  sense  of  a large  collection  of 
constructs  --  each  of  which  is  "just  right"  for  a particular  situation.  We  believe  that  we  have. 
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however,  supported  expressiveness  in  a larger  sense  by  encouraging  program  organizations  which 
convey  important,  abstract  information  about  the  way  that  the  program  works. 

Similarly,  we  have  emphasized  safety  and  efficiency,  sometimes  at  the  expense  of  brevity  or 
convenience.  This  has  led  us  to  restrict  some  traditional  constructs  (e.g.,  scope  and  parameter  rules) 
and  refrain  from  making  some  tempting  generalizations.  We  are  aware  of  many  areas  in  which  the 
present  design  could  be  generalized  in  rather  obvious  ways;  we  have  chosen  not  to  do  so,  however, 
when  we  might  compromise  the  programmer's  confidence  in  both  the  correctness  and  performance  of 
his  program1 


1.1.  Unusual  Aspects  of  the  Language 

Many  aspects  of  programming  languages  have  become  fairly  standard  in  the  past  decade.  Alphard 
constructs  are  intentionally  similar  in  style  and  meaning  to  the  analogous  constructs  in  other  languages. 
In  particular,  we  have  leaned  heavily  on  the  Algol-Pascal  culture;  the  syntax  of  expressions,  variable 
declarations,  procedures,  and  so  on,  are  alt  derived  from  this  culture.  The  following,  for  example,  is  a 
fragment  of  a valid  Alphard  program  and  is  obviously  similar  to  Pascal: 
begin 

var  x,y,z:lnt; 

If  x2y  then  z:«z*1  fi; 

end; 

We  expect  that  the  similarity  between  the  Alphard  constructs  and  the  analogous  ones  in  other 
languages  will  aid  both  the  reader  of  this  report  and  the  programmers  who  use  the  language. 

There  are,  however,  a number  of  aspects  of  the  language  which  differ  significantly  from  many 
traditional  languages.  This  section  provides  brief  notes  on  these  aapects  of  Alphard.  It  la,  In  affect,  a 
list  of  points  at  which  the  reader  should  be  aware  that  things  may  not  be  as  expected. 

1 . Typo  Definitions:  The  programmer  may  define  a new  type  through  a construct  called  a form. 

The  form  permits  both  the  specification  of  the  abstract  properties  of  (objects  of)  the  new 
type  and  the  implementation  of  that  type  in  terms  of  pre-existing  types.  Type  definitions 
(forms)  may  be  parameterized;  in  particular  they  may  accept  other  form  names  as 
parsmeters.  Such  forma  are  called  "generic*  and  define  a class  of  types  (e.g.,  array(T), 
where  T is  a type,  defines  array-of*integer,  array-of-real,  array-of-set-of-lnteger,  etc.). 

2.  Primitive  types:  Integer,  real,  complex,  etc.  are  not  primitive  types  in  Alphard;  similarly, 
structures  such  as  arrays,  records,  and  references  (pointers)  are  not  primitive.  All  of  these 
familiar  notions  are  available,  however.  Either  they  are  provided  as  "syntactic  sugar" 
through  some  standard  abbreviations,  or  else  they  are  made  available  to  the  programmer  as  a 
part  of  a "standard  prelude"  — a set  of  standard  definitions  which  (conceptually)  prefaces 
every  program.  Specifications  for  the  standard  prelude  are  Included  as  appendix 
B to  this  report. 


1 We  are  convinced  that  deciding  what  not  to  include  in  a language  design  is  much  harder  than  inventing  clever 
new  things  to  include. 
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There  are  (only)  two  distinguished  types  in  Alphard;  they  are  distinguished  in  the  sense  that 
they  must  be  considered  as  part  c 1 the  language  and  not  as  part  of  the  standard  prelude. 
They  are  "rawstorage"  and  “boolean".  Specifications  of  these  types  and  their  associated 
operations  may  be  found  In  appendix  B;  Informally,  however; 

a.  Type  "rawstorage":  This  type  corresponds  to  a vector  of  contiguous,  addressable, 
untyped  memory  "cells"  of  conventional  computers  (we  shall  refer  Informally  to  a 
rawstorage  unit  of  length  one  as  a "cell"  or  a "word"  but  we  make  no  a 
committment  to  the  number  of  bits  in  each  such  cell);  bit-wise  logical,  shifting,  and 
integer  operations  are  defined  on  cells.  All  other  types  are  (ultimately) 
represented  in  terms  of  objects  of  type  rawstorage,  and  the  definition  of  this  type 
contains  the  basic  mechanism  for  associating  a "higher  level”  type  with  an  area  of 
storage.  Type  rawstorage  is  distinguished  (only)  because  'ts  implementation 
Cannot  be  expressed  in  the  language. 

b.  Type  "boolean":  Objects  of  type  boolean  are  primitive  (unstructured),  and  possess 
values  from  a set  designated  {true, false).  Type  boolean  is  distinguished  In  the 
sense  that,  although  it  can  be  defined  in  terms  of  Type  rawstorage,  it  is  needed 
for  the  definition  of  other  language  constructs  --  e.g.,  the  conditional  statement. 

The  customary  operations  are  provided. 

3.  Type  Checking : Most  modern  programming  languages  contain  some  notion  of  the 
"equivalence"  of  types  and  require  that  the  types  of  actual  parameters  to  procedures  be 
equivalent  to  those  specified  by  the  corresponding  formal  parameter  definitions.  The 
presence  of  parameterized  and  generic  type  definitions  In  Alphard  makes  it  advantageous  to 
replace  the  notion  of  equivalence  by  a more  liberal  notion  of  "matching".  Formal  parameter 
definitions  specify  a collection  of  properties  which  the  corresponding  actual  parameter  must 
possess,  specify  a collection  of  properties  which  are  irrelevant,  and  provide  a limited  facility 
for  relating  properties  of  distinct  parameters.  Together  these  define  a class  of  valid  actual 
parameter  types,  and  provide  what  is  generally  called  "strong  typing";  In  particular,  the 
parameter  specification  and  matching  is  sufficiently  strong  to  ensure  venfiabillty. 

4 Scope  Pules-.  Alphard's  block  structure  is  similar  to  that  of  Algol  60:  declarations  appear  at 
the  head  of  a block,  the  meaning  of  an  identifier  is  determined  from  Its  nearest  enclosing 
declaration,  and  so  on.  Unlike  Algol,  however,  in  Alphard  the  bodies  of  procedures  and  forms 
do  not  inherit  the  names  of  variables  available  in  enclosing  blocks.  The  intent  of  these  scope 
restrictions^  is  to  ensure  that  all  effects  of  an  action  can  be  determined  by  examining  the 
text  immediately  surrounding  the  action  itself.  An  additional  benefit  is  that  Alphard  can  be 
implemented  (very  efficiently)  using  a stack,  but  without  the  need  for  a display. 

5.  Operator  Overloading:  The  meaning  of  the  usual  infix  operators  (e.g.,  etc.)  may  be 

extended  to  programmer-defined  data  types.  The  symbols  for,  the  associativity  of,  and  the 
precedence  of  these  operators  are  fixed  by  the  language  (see  appendix  C). 

I 

^ A particular  consequence  of  the  scope  'estnetions  --  together  with  companion  restrictions  on  overlapping  actual 
parameters  and  selectors  — is  to  prevent  unintended  "aliasing’.  That  is,  they  ensure  that  within  a given  scooe 
there  is  at  most  one  name  for  a given  storage  cell. 
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6.  Selectors:  The  programmer  may  define  the  representation  of  a data  structure  by  means  of  a 
selector.  Intuitively,  a selector  defines  an  algorithm  for  naming  data,  just  as  a procedure  or 
function  defines  an  algorithm  for  computing  va'ues.  A selector  may  be  thought  of  as  a 
procedure  that  returns  a pointer  (reference,  address)  to  an  element  of  a data  structure;  the 
syntax  for  defining  selectors  Is  therefore  similar  to  that  of  procedures.  "Pointer"  Is  not, 
however,  a type  in  Alphard;  no  variables  of  this  type  can  be  declared,  and  hence  the  "value" 
returned  by  a selector  cannot  be  stored.  The  effect  of  this  (coupled  with  some  verification 
requirements)  is  that  selectors  are  "safe";  most  of  the  (useful)  flexibility  of  general  address 
arithmetic  is  retained  without  introducing  Its  corresponding  dangers.  In  particular,  It  is 
possible  to  define  a restricted  style  of  "reference"  variable  completely  within  the  language 
and  to  ensure  that  this  type  Is  at  least  as  safe  as  array  indices  In  other  languages. 

7.  Assertions:  Assertions  are  permitted  almost  everywhere  and  special  syntax  encourages 
their  use  in  appropriate  places.  The  language  In  which  the  assertions  are  written,  however, 
is  not  defined  by  Alphard.  The  choice  of  that  language  Is,  we  believe,  a private  matter 
between  the  programmer  and  verifier. 

8.  Iteration:  Four  iteration  statements  are  provided,  three  of  which  are  somewhat  different 
from  what  one  might  expect. 

a.  The  do  statement  repeats  its  body  until  the  body  invokes  an  explicit  exit. 

b.  The  for  statement  serves  a function  similar  to  the  for- step- untH  construct  of  Algol 
60,  but  does  so  in  a manner  that  permits  the  programmer  to  define  the  type  of  the 
conti ol  variable,  the  way  it  is  initialized  and  incremented,  and  the  nature  of  the 
test  for  completion  of  the  loop.  These  aspects  of  loop  control  are  all  defined  in  a 
form  (usually  a specialized  form  called  a generator). 

c.  The  first  statement  provides  a special  syntax  for  those  common  loops  that  search 
a data  structure  and  perform  one  of  two  actions  depending  upon  whether  or  not  an 
element  with  a specified  property  is  found. 

The  fourth  iteration  construct  is  the  familiar  while  statement. 

9.  Sugaring:  A number  of  familiar  notions  such  as  records  and  enumerated  types  are  not 
primitive  notions  in  Alphard.  They  are  provided,  however,  as  abbreviations  for  the  more  basic 
notions  from  which  they  are  formed3 


1 .2.  Style  and  Conventions  of  the  Report 

This  report  is  a precise  but  informal  definition  of  Alphard;  It  is  neither  a primer  nor  a completely 
rigorous  formal  definition.  It  Is  Intended,  however,  to  be  the  reference  for  users,  Implementors,  and 
verifiers.  To  that  end  we  have  attempted  to  be  as  precise  as  our  human  limitations  and  the  vagaries  of 
English  permit.  We  have  consciously  adopted  the  style  and  tone  of  the  Algol  60  report,  which  we 
believe  remains  the  exemplar  language  definition. 

The  syntactic  definition  of  the  language  uses  conventional  BNF  with  the  following  additions  and 
conventions: 
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1 . Key  words  (reserved  words)  are  denoted  by  underlining. 

2.  Metasymbols  are  denoted  by  lower-case  letters  enclosed  In  angular  brackets,  e.g.,  ''<3tmt>n. 

3.  The  symbols  { and  > are  meta-brackets  and  are  used  to  group  constructs  In  the  meta- 
notation. 


4.  Three  superscript  characters,  possibly  in  combination  with  a subscript  character,  are  used  to 
denote  the  repetition  of  a construct  (or  a group  of  constructs  enclosed  in  {}).  In  particular: 
denotes  "zero  or  more  repetitions  of" 
denotes  "one  or  more  repetitions  of" 
denotes  "precisely  zero  or  one  instance  of". 

Since  It  is  often  convenient  to  denote  lists  of  things  that  are  separated  by  some  single 
punctuation  mark,  we  denote  this  by  placing  the  punctuation  mark  directly  below  the 
repetition  character.  Thus, 


<vvv»  <a»  { <b>  | <c>  ) 

a defines  a <vvv>  to  be  an  <a»  followed  by  either  a <b>  or  a <c>. 

<»x»>  <a» 

t defines  an  <xx*>  to  be  a sequence  of  zero  or  more  a’s. 

<yyy>  <a>  <b>, 

defines  a <yyy>  to  be  an  <a>  followed  by  zero  or  more  <b>s  separated  by 
commas. 

<zzz>  {<a>  | <b»j* 

defines  a <zzz>  to  be  a sequence  of  one  or  more  things  separated  by 
semicolons  — where  the  "things’  may  be  either  <a>s  or  <b>s. 

<uuu>  <a>*  <b> 

defines  <uuu>  to  be  either  *<axb>’  or  simply  "<b>* 


The  semantics  of  the  language  are  described  in  English.  Proof  rules  for  some  constructs  are  provided 
in  appendix  E. 

Certain  portions  of  this  report  describe  processes  in  terms  of  extra  variable  creations,  text 
replacements  (copying),  or  other  actions.  These  are  Informal  expositions  and  at  all  times  the  language 
(compiler)  Is  required  to  only  produce  the  same  net  semantic  effect.  Such  expositions  should  be 
interpreted  in  their  intended,  helpful  sense.  Obscure  consequences  of  the  particular  processes  will  not 
be  supported. 
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Chapter  2 

Fundamental  Concepts 

The  following  chapters  define  the  syntax  and  semantics  of  Alphard;  In  this  chapter  we  describe 
certain  pervasive  notions  that  are  used  in  the  definition. 

A complete  Alphard  program  consists  of  a collection  of  declarations  and  statements  which  are 
elaborated4  to  produce  some  desired  effect.  Declarations  define  forms  (which,  In  turn,  define  classes 
of  types),  routines9  (which  may  be  Invoked  to  evoke  further  elaboration),  variables,  and  a number  of 
other  entities  of  lesser  Immediate  importance.  Statements  define  actions  to  be  performed;  they  may 
specify  selective  or  iterative  elaboration  of  component  statements  and  expressions.  Of  particular 
immediate  Interest,  because  they  cover  the  major  ideas  we  wish  to  discuss,  are  the  notions  involved  in 
the  elaboration  of  the  declaration  of  variables  and  in  the  elaboration  of  routine  invocations. 

The  elaboration  of  a variable  declaration,  a.g. 
var  x:vector(int,1 ,1 0) 

begins  wth  elaboration  of  the  type  description  (vector(int,1,10)),  followed  by  Instantiation  of  an 
object  uf  the  type  resulting  from  this  elaboration  (Instantiation  involves  both  allocation  and 
Initialization)-,  finally,  a binding  of  the  name  to  the  Instantiation  is  performed. 

The  elaboration  of  a routine  invocation,  e.g., 
f(x,y) 

begins  with  the  elaboration  of  the  actual  parameters  (x  and  y),  followed  by  matching  of  the  nominal 
type  of  the  actual  parameters  with  the  type  descriptions  of  the  positionally  corresponding  formats;  If 
this  matching  succeeds  a set  of  bindings  is  performed6  and  the  routine  body  Is  elaborated. 

The  words  and  phrases  in  bold-face  above,  type,  object,  ._,  are  representative  of  the  notions  we 
shall  discuss  In  this  chapter.  Because  of  mutual  dependencies  between  the  notions,  however,  we  shell 
not  discuss  them  in  precisely  the  order  In  which  they  are  mentioned  above.  We  have  chosen  Instead 
an  order  which  attempts  to  minimizes  the  forward  references. 


2.1 . Objects,  Addresses,  and  Values 

Intuitively  an  object  Is  a generalized  (and  typed)  storage  cell,  or  variable;  it  Is  used  to  hold  the 
value  of  some  abstract  data  type. 


4 We  use  the  word  "elaboration*  in  preference  to  "execution",  to  connote  actions  taken  at  "compile  time*  oj  well 
<u  or  "run  time*.  Elaboration  may  be  thought  of  as  an  idealized,  direct  execution  of  the  textual  version  of  the 
Aiphsrd  program. 


9 The  word  "routine*  is  used  systematically  to  cover  the  notions  of  proc.  vproc.  furc.  and  ill. 
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At  this  point  a result  object  may  also  be  instantiated,  but  this  is  not  essential  to  the  present  discussion. 
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An  object  possesses  a unique  (generalized)  address,  a type,  and  a value  (or  state).  Objects  may 
be  dynamically  created  and  destroyed.  The  address  and  type  of  "an  object  are  fixed  throughout  Its 
lifetime,  but  the  value  it  possesses  may  be  altered. 

An  object  may  be  primitive,  In  which  case  its  values  (l.e.,  the  values  it  may  possess)  are  members  of 
an  arbitrary  set.  Otherwise,  the  object  is  composed  of  a sequence  of  one  or  more  (previously  created) 
objects,  called  its  concrete  components.  The  value  of  such  an  object  may  be  taken  to  be  the 
sequence  of  values  of  its  concrete  components.  For  the  purpose  of  the  following  exposition,  If  x 
denotes  an  object.  X|  denotes  its  i*h  component  object. 

Two  objects  may  overlap;  that  is.  their  values  need  not  be  independent.  A common  case,  though  not 
the  only  one,  is  that  one  object  wholly  contains  the  other,  as  a vector  contains  Its  elements.  Two 
objects  that  do  not  overlap  are  called  Independent.  Any  logical  dependency  (i.e.,  overlap)  between 
the  values  of  two  objects  is  fixed.  A newly  created  object  independent  of  all  previously  existing 
objects  Is  called  a new  object. 

The  creation  of  an  object  is  generally  associated  with  allocation  of  storage  for  the  object  and 
initialization  of  its  value.  The  entire  process  is  called  Instantiation  and  the  resulting  object  is  called 
an  instantiation  of  its  type.  The  first  step  of  instantiation  is  the  elaboration  (evaluation)  of  a type 
description  to  yield  a type  (see  section  5.6).  Next  the  object  is  created.  For  primitive  objects 
this  is  a direct  operation;  otherwise  it  is  achieved  by  (recursive)  Instantiation  of  its  concrete 
components.  (Note  that  at  the  moment  of  creation  the  generalized  address  of  the  object  is 
determined.)  After  allocation,  the  initialization  procedure  defined  with  the  base  type  of  the  object  Is 
invoked  as  described  in  section  5.5. 

Objects  are  destroyed  by  first  invoking  a finishing  procedure  defined  with  the  base  type  of  the 
object  (as  described  in  section  5.5),  then  de-allocating  the  object  (for  primitive  objects)  or 
destroying  its  concrete  components  (for  non-primitive  objects). 


2.2.  Type  and  Type  Descriptions 

Intuitively,  type  is  that  property  of  an  object  which  defines  its  possible  behaviors''  . More  formally,  a 
type  characterizes  the  possible  values  (states)  of  an  object  and  the  set  of  operations  that  may  be 
applied  to  it. 

There  are  two  explicit  syntactic  manifestations  of  the  notion  of  type  in  the  language;  form 
declarations  (which  define  a class  of  types),  and  type  descriptions  (which  describe  a class  of  object 
types  that  may  be  bound  to  an  identifier  in  declarations  or  formal  parameter  specifications). 

Form  declarations  are  defined  in  section  5.9.  For  our  present  purposes  It  Is  sufficient  to 
note  that:  (1)  every  form  has  a name,  (2)  a form  may  be  parameterized,  and  (3)  the  form  declaration 
makes  available  various  operations.  A subset  of  these  operations  (the  side-effect  producing  ones)  is 
called  the  update  set. 


Ncte  that  objects,  not  values,  are  typed,  indeed  naked  values  do  not  exist  in  Alphard  — values  only  exist  in 
objects.  Thus,  for  example,  we  may  soeah  informally  of  the  ‘value  produced  by  a procedure',  but  in  tact  the 
procedure  returns  an  object  that  contains  the  vaiue. 
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Typ«  descriptions  are  used  In  three  contexts:  (1)  In  variable  declarations,  where  they  define  the 
type  of  an  object  to  be  instantiated,  (2)  in  formal  parameter  specifications,  where  they  define  the 
class  of  legal  actual  parameters,  and  (3)  In  routine  definitions,  where  they  specify  the  type  of  the 
object  returned.  In  addition,  in  both  contexts  type  descriptions  define  the  nominal  typo  of  arty  object 
bound  to  a particular  Identifier.  Thus,  the  nominal  type  of  an  object  Is  the  information  about  Ita  typo 
that  can  be  inferred  by  accessing  the  object  through  a particular  identifier. 

The  distinction  drawn  In  the  last  paragraph  between  "type*  and  'nominal  type”  Is  an  Important, 
though  possibly  subtle,  one.  A 'type*  is  associated  with  an  object  and  determines  all  possible 
behaviors  of  that  object.  A 'nominal  type'  is  associated  with  an  identifier  which,  in  turn,  Is  bound  to  an 
object.  The  nominal  type  associated  with  an  identifier  determines  the  possible  behaviors  that  can  be 
caused  through  that  identifier.  In  the  general  case  a nominal  type  will  be  'less  specific'  than  the  type 
of  the  object  to  which  the  Identifier  Is  bound. 

In  the  following  sections  we  more  formally  define  the  notions  of  type,  type  descriptions,  and  nominal 
type. 

2.2.1  Type 

A type  results  from  the  elaboration  of  a type  description  (see  section  5.S)  and  consists  of  a 
base  type,  a (possibly  null)  sequence  of  actual  type  qualifiers,  and  an  update  set. 

A bee#  type  is  a form  name;  it  uniquely  identifies  a class  of  types.  For  example,  the  base  type  of 
" veetc»<  real.  1,10)*  is  'vector'.  In  the  following,  If  T Is  a typo,  Bese(T)8  represents  the  base  type  of 
T 


An  actual  type  qualifier  is  intuitively  an  actual  parameter  in  a type  description;  hence  it  corresponds 
to  a formal  parameter  in  a form  definition.  It  may  be  an  object  address,  an  object,  a routine  name,  a 
type,  or  a marker  denoted  unk®\  in  "vector<  real.  1,10)',  the  actual  type  qualifiers  are  "real*,  "1",  and 
"10'. 


A type  none  of  whose  qualifiers  is  unk  is  called  a full  type:  a type  with  at  least  one  unk  qualifier  Is 
called  a partial  type. 

The  update  set  consists  of  a set  of  routine  designators  *rom  among  those  defined  with  the  base 
type;  specifically,  the  update  set  consists  of  those  routines  which  may  have  a (visible)  effect  on  an 
object  of  the  type.  If  T is  a type,  Update<T)  denotes  ita  update  set 

If  T la  a type,  then  Qual(T)  denotes  the  sequence  of  actual  type  qualifiers  of  T and  i3ual|(T)  denotes 
the  Ith  element  of  that  sequence. 


3 Here  and  in  the  sequel  we  shall  use  functions  such  aa  Basa(I),  Quef(T),  Uedateik),  etc.  to  explain  semantic 
aspects  of  the  language;  these  (unctions  are  only  part  of  the  semantic  exposition,  not  constructs  in  the  language 
itself. 


® The  marker  unk.  which  ia  to  be  reec  ‘unknown’,  denotes  situations  in  which  the  corresponding  form  formal  is 
not  considered  a part  of  the  nominal  type. 
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2.2.2  Typo  Descriptions 

A typo  description  is  a syntactic  construct  which  describes  a class  of  types  and  may  designate 
restricted  access  to  objects  of  those  types.  A type  description  consists  of  a base  type,  a sequence 
of  formal  type  qualifiers  and  an  update  set.  The  elaboration  of  a type  description  yields  a type  or  a 
nominal  type. 

A base  type  is  (as  above)  a form  name. 

A formal  type  qualifier  is  either  the  marker  unk  or  else  a description  of  an  object  address,  an  object, 
a routine,  or  a type.  When  used  to  specify  a formal  parameter,  a formal  type  qualifier  may  be  an 
identifier  preceded  by  a "7"  symbol;  in  such  cases  an  "implicit  binding"  is  implied  (see  section 
2.4). 

The  update  set  consists  of  a set  of  routine  names  from  among  those  defined  with  the  base  type. 
Update  sets  give  restrictions  on  the  effect-producing  actions  that  may  be  applied  to  an  object^®  . If  0 
Is  a type  description,  'Jpdate(D)  denotes  its  update  set. 

2.2.3  Nominal  Type 

A nominal  type,  like  a type,  consists  of  a base  type,  a (possibly  null)  sequence  of  actual  type 
qualifiers,  and  an  update  set.  These  notions  are  defined  exactly  as  in  the  definition  of  type. 

A type  is  always  associated  with  an  object.  A nominal  type,  on  the  other  hand,  is  always  associated 
with  an  Identifier.  The  nominal  type  of  an  identifier  may,  in  the  general  case,  be  less  specific  than  the 
type  of  the  object  to  which  that  identifier  is  bound;  however,  the  type  of  an  object  will  always  match 
the  nominal  type  of  the  identifier. 


2.3.  Binding 

During  elaboration,  some  identifiers  become  associated  with  --  bound  to  — entities;  these  entities 
may  be  objects,  routines,  or  types.  The  binding  of  identifiers  to  objects  is  of  particular  Interest  and 
includes  both  the  declaration  of  variables  (and  associated  instantiation  of  an  object)  and  parameter 
passing. 

In  all  contexts  in  which  an  identifier  may  become  bound  to  an  object  (i.e..  In  a variable  declaration  or 
formal  parameter  position)  there  is  an  associated  type  description.  In  the  case  of  a variable 
declaration,  this  description  determines  the  type  of  the  object  created.  In  the  case  of  a formal 
parameter,  the  type  description  defines  the  types  of  allowed  actual  parameters.  In  both  cases, 
however,  the  type  description  is  elaborated  to  a nominal  type  which  determines  the  permitted  uses  of 
the  object  identified  through  this  identifier. 


In  practice  we  allow  more  than  |ust  the  name*  o(  effect-producing  operation*  in  the  update  set  part  of  certain 
type  descriptions,  notably  those  which  specify  generic  formal  parameters.  In  such  cases  we  allow  non-effect- 
producing  attribute  names  as  well;  this  is  merely  a shorthand  for  an  ‘assumes  clause*  (sea  faction  5.12). 
This  abbreviation  is  permitted  because  of  its  similarity  of  intent  to  the  update  sat:  it  describes  a set  of  attributes 
which  the  routine  or  iprm  body  requires  for  correct  operation. 
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In  both  declarative  and  formal  parameter  positions  the  description  of  a binding  may  be  preceded  by 
either  var  or  const.  The  only  difference  between  the  two  is  that  In  the  latter  case  (const)  the  update 
set  of  the  Identifier  is  set  to  empty;  in  the  former  (var)  case  the  update  set  is  determined  from  the 
associated  type  description.  A particular  consequence  of  this  mechanism  Is  that  parameters  in  const 
positions  are,  intuitively,  passed  "by  reference"  but  cannot  be  modified  by  the  called  procedure. 

if  It  Is  an  identifier  bound  to  an  object,  then  we  refer  to  this  object  as  Obj(k)  and  to  Its  associated 
nominal  type  as  Type(k). 


2.4.  Type  Matching 

The  process  of  parameter  binding  requires  a notion  of  what  it  means  for  an  actual  parameter  to 
match,  or  satisfy,  a formal  parameter  specification.  Intuitively  this  process  Involves  determining  that 
the  nominal  typo  associated  with  the  formal  parameter  "Includes",  or  "covers",  the  nominal  type  of  the 
actual  --  that  is,  ensuring  that  the  behaviors  permissible  through  the  formal  parameter  name  are  among 
those  permissible  through  the  actual  parameter  name.  For  simplicity  we  break  this  process  Into  three 
subprocesses:  subsumption,  syntactic  satisfaction,  and  implicit  binding.  Each  of  theae  is  uaed  for  a 
different  kind  of  actual/formal  matching  as  specified  below. 

A list  of  actual  parameters 
“1 «n 

is  said  to  match  a list  of  formais 
1 1 :t1  • f2:t2 fn:tn 

where  the  a;  are  objects,  types,  or  routine  names,  if  there  exists  a binding  of  objects,  types,  and 
routines  to  the  implicit  formais  In  the  tj  such  that  If  each  f|  Is  bound  to  a|,  then  for  each  I, 

1 . If  tj  Is  a description  of  a routine  (proc.  vproc,  func.  or  sal),  then  a^  Is  the  name  of  a "proc",  ...» 
or  "sel"  with  formal  parameters  Identical  to  those  of  t|  after  possible  renaming  of  formal 
parameters. 

2.  If  t,  is  "form"  (or  "pform).  then  a,  is  a type  (if  a,  Is  a partial  type  t,  must  hove  been  pform) 
and  the  assumed  definition  of  f|  (see  section  5.12)  la  syntactically  satisfied  (see 
section  2.4)  by  a|. 

3.  If  t,  is  a type  description,  then  a,  must  be  an  object  such  that  when  tt  is  elaborated,  t| 
subsumes  Type(a|). 

In  addition,  all  implicit  formais  bound  to  types  must  be  bound  to  types  syntactically  satisfying  the 
assumed  definition  of  the  form  (see  section  5.12). 

The  notions  of  subsumption,  syntactic  satisfaction,  and  implicit  binding  are  defined  below;  we  begin 
with  the  notion  of  subsumption  ••  the  kind  of  matching  used  when  an  object  parameter  Is  expected. 
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Definition,  We  say  that  a (nominal)  type  Tf  subsume*  a (nominal)  type  Ta  (in  symbols,  Tf>>Ta) 
Iff: 

1.  Base(Tf)  ■ Base(Ta). 

2.  length(Qual(Tf))  5 length(Qual(Ta)).  Note:  if  length(Qual(Tf))  < length(Qual(Ta)),  the 
formal  qualifier  sequence  of  Tf  Is  extended  on  the  right  with  a sufficient  number  of 
unk's. 

3.  For  each  qualifier  of  Tf,  i.e.,  Qualj(Tf): 

a.  If  Qual|(Tf)  is  unk,  Qual,(Ta)  may  be  anything. 

b.  If  Qual,(Tf)  is  a type,  Qual|(Ta)  is  also  a type  and  Quai|(Tf)>>Qual|(Ta) 

c.  If  Qual|(Tr)  describes  a routine,  then  Qual;(Ta)  Is  also  a routine  and  Qual^Tg) 
matches  Quatj(Tf). 

d.  If  Qual,(Tf)  is  an  object  of  base  type  U,  Qual,(Ta)  is  also  an  object  of  base 
type  U and  the  value  of  the  result  of  applying  i*  for  U to  Quat|(Tf)  and 
Qual|(Ta)  would  be  true. 

4.  Update(Tf)  c Update(T#). 

In  some  cases  condition  3d  cannot  be  checked  at  compile  time.  At  the  discretion  of  the  Implementors, 
the  compiler  may  provide  the  options  of  generating  warnings,  generating  checking  code,  or  refusing  to 
compile  such  cases. 

Definition,  Two  types  are  Identical  if  each  subsumes  the  other. 

In  Alphard,  both  routines  and  forms  may  be  "generic".  That  is,  they  may  require  types  as  parameters 
— or,  equivalently,  they  may  have  parameters  whose  type  is  not  specified  In  the  routine  (form)  header. 
In  such  c ises  there  will  be  an  "assumes  clause"  which  specifies  the  properties  that  the  routine  (form) 
assumes  about  the  generic  parameter;  this  clause  gives  sufficient  information  to  check  all  uses  of  the 
parameter  locally.  In  order  for  a given  use  of  the  form  or  routine  to  make  sense,  the  actual  parameter 
must  at  least  meet  the  syntactic  assumptions  made  about  it.  Thus  the  notion  of  matching  formal  and 
actual  parameters  In  such  cases  involves  of  determining  whether  the  actual  parameter  syntactically 
satlaflea  the  formal  parameter  assumptions  1 1 . 
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Vfors  generally,  of  course,  a proof  will  be  required  to  demonstrate  that  the  actual  parameter  maket  semantic 
se  as  well. 
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Doflnltl on,  Given  an  assumed  declaration  of  a generic  parameter,  T: 
form  T 
specs 

{definitions  of  fj...fn> 
and  a candidate  actual  type 
Q(a-)  ,a2,—) 

whose  base  type  is  declared 
form  Q(p1(...) 
specs  ... 

we  say  that  the  type  a(a1(...)  syntactically  satisfies  T if  textual  substitution  of  "Q(a1 ,...)"  for 
“T"  uniformly  throughout  the  specifications  of  T results  In  T’s  specifications  containing 
declarations  of  f ■)  ,...fn  identical  to  those  In  Q's  specifications  (ignoring  assertions  and 
implementations),  though  possibly  only  after  suitable  renaming  of  formal  parameters. 

In  the  process  of  determining  whether  an  actual  parameter  of  type  T matches  a formal  parameter 
specification  we  may  discover  that  Quaij  of  the  formal  is  an  identifier  preceded  by  "?".  Such  identifiers 
are  called  "Implicit  formal  parameters",  and  are  "Implicitly  bound"  to  corresponding  (qualifiers  of  the) 
actual  parameters.  Such  bindings  are  performed  before  other  matching. 

Doflnitlon,  Let  Tf  be  the  formal  type  and  T,  be  the  actual  type.  If,  In  determining  whether 
Tf»Ta,  Base(Tf)  or  Qual|(Tf)  is  an  Identifier  preceded  by  a "?",  the  Identifier  is  Implicitly 
bound  to  the  corresponding  Base(Ta)  or  Ouatj(Ta)  and  becomes  an  "Implicit  formal  parameter". 
The  nominal  type  of  an  implicit  formal  is  made  identical  to  the  nominal  type  of  the  corresponding 
f°rm  formal.  Note  that  only  one  binding  is  established  for  such  Identifiers,  so  multiple 
occurrences  must  be  consistent. 

In  the  procedure  declaration 

proc  P(x:vector(int,?lb,?ub))  is  ... 

for  example,  "lb"  and  "ub"  are  such  Implicit  formals.  They  are,  respectively,  the  lower  and  upper 
bounds  of  an  actual  parameter  vector.  Thus,  if  some  program  fragment  contains 
...  var  y:vector(int,  1,  1 0);  ...  P(y)  ... 

then  1 and  1 0,  respectively,  will  be  implicitly  bound  to  the  formals  lb  and  ub. 

V 

The  following  table  attempts  to  recap  the  essential  aspects  of  the  notion  of  actuel/formei  parameter 
matching: 


Formal 

Actual 

x:form 

full  type 

X:pform 

type 

x: {routine  description) 

routine  name 

X:?T 

object 

x:{type  description) 

object 

object 

object 

unh 

anything 

?T 

match  after 

routine  name 

routine  name 

Matching  Rule 

syntactic  satisfaction 
syntactic  satisfaction 
point  3 of  match  rule 

Type(object)  must  syntactically  satisfy  T 
subsumption 

equality  under  4"  for  the  type  of  the  formal 
always  matches 
ipliclt  binding 
same  routine 


I 
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Chapter  3 

Sasic  Lexica / Structure 


3.1.  Symbols 

<letter>  A | B (...(  Z I a ( . . . | z 

<digit>  0 | 1 | ...  | 9 

alphanumeric*  Oetter*  | <digit»  | ' 

<special  $ymboi>  <basic  symbol*  j <oparator* 

<basic  symool*  beam  | gnd  | endof  | ; | : | ( | ) | t | , | ::  | Si  I 

if  | then  | else  | fi  | case  | 

5*.  I esse  t <3,  | with  1 in  | ni  | first  | suchthat  | trom  I do  I Od  I 

tgr  | osifloop  | leave  | siu^  | assert  | 

var  | const  | ay*  | as  specked  I - I init  | 

final  ( unk  | » | proc  | vproc  | tunc  | sjl  | label  | 

note  | eton  | ! | glif  | elof  | aform  | while  | * | < | . ( • | 

COPY  I alias  I form  | inline  | gre  | post  | rule  | 
is  | forward  | estemat  | specs  I imp)  | shared  | 
invariant  | initially  | a»iom  | reomap  | 
record  I enumerated  | assumes  I value  | generator 
<operator»  <bin»ry  operator*  | <unary  operator* 

<bin»ry  operator*  1 I • I / I iv  | rjm  |*|-|<|s|.|o|j>|>|  jjmj  | gr  | cand  | jyr  | ijn^  | 

<assign  op* 

<unary  operator*  ♦ I - I ngt 

Typographical  features  such  as  blanks  (spaces),  ends  of  tines,  etc.,  are  generally  not  significant  (but 
see  section  3.4.3);  an  implementation  may  use  them  to  aelimit  identifiers,  numbers,  etc.  Outside 
strings,  no  such  features  may  appear  immediately  after  the  symbol  ”&”  or  *?",  or  around  the  symbols 
and  “$"  when  they  are  used  as  described  In  sections  3.4.2  and  4.3. 

Upper  and  lower  case  letters  are  distinct.  Also,  note  that  the  grave  symbol  Is  considered  a 
(significant)  alphanumeric  and  thus  may  be  used  in  constructing  identifiers;  It  Is  Intended  thet  this  be 
used  to  improve  program  readability  by  separating  mnemomcally  signifeant  portions  of  such  Identifiers. 

Basic  symbols  such  as  begin  era  conceptually  singla  characters  and  art  underlined  in  this  report  to 
emphasize  that  fact.  An  implementation,  however,  must  reserve  (all  upper /lower  case  spallings  of)  the 
corresponding  identifiers  to  denote  these  symbols.  Thus  ’BEGIN”,  "begin",  "Begin”,  etc.  ere  ell 
Interpreted  as  the  basic  symbol  begin;  wa  strongly  encourage,  however,  consistent  use  of  one  spelling 
in  a given  program. 


3.2.  Comments 

The  following  two  commenting  construots  are  lexically  equivalent  to  a space  (blank)  character  when 
they  appear  outside  of  strings. 

note  <any  sequence  not  containing  the  lexeme  "aton”>  eton 
Kany  sequence  up  to  end  of  line) 

The  first  commenting  construct  encountered  in  a lina  takes  preceoence  over  any  contained  within  it. 


3.3.  Identifiers 

3.3.1  Syntax 


identifier* 
<special  identifier* 
identifier  list* 
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ietter*  (alphanumeric*)* 

{start  | {finish  | 4 next  | 4 done  | {rvalue  | {subscript  | {<operator* 
identifier*, 


3.3.2  Examples 
A 

a3 

TheOogTheCetChased 

The'Dog'The'Cat'Chased 

the'dog'the'cat'cheeed 

start 

{start 

{■ 

All  the  above  identifiers  are  distinct. 

3.3.3  Semantics 

Identifiers  have  no  Inherent  meanings.  They  identify  objects,  forms,  types,  procedures,  seiectors, 
statements,  and  parameters.  Declarations  establish  the  meanings  of  Identifiers  within  particular 
scopes. 

Two  identifiers  ere  dufined  to  be  similar  if  they  differ  at  most  In  the  typographical  case  used  to 
spell  them;  thus  "ABC*,  "Abe",  "aBc",  etc.  are  aH  similar.  Except  when  used  as  routine  names,  similar 
identifiers  may  not  be  declared  In  the  same  scope  ^ . 

Special  Identifiers  denote  entities  of  special  significance  in  the  language.  They  may  be  defined  but 
never  directly  referenced;  they  are  invoked  as  the  consequence  of  using  some  other  construct  defined 
by  the  language.  A simple  example  of  the  use  of  such  symbols  appears  in  section  3.4.1,  where 
the  language-defined  notion  of  *♦"  invokes  the  user-definable  function  named  more  Interesting 

examples  may  be  found  In  sections  4.7  and  4.8.  (Requirements  on  the  definitions  of 
such  routines  appear  In  appendix  C.) 


3.4.  Special  Rewrite  Rules 

In  order  to  simplify  the  language  definition,  a number  of  familiar  and  convenient  notations  are 
provided  Indirectly  rather  than  as  a part  of  the  syntax.  To  accomodate  these,  we  defire  several 
"rewrite  rules"  that  transform  programs  from  the  store  familiar  notation  to  that  described  by  the  report. 
These  transformations  convert  Infix  operators  to  function  invocations,  provide  "qualified  names",  and 
Introduce  semicolons.  We  shall  use  the  notation  — > Cj  to  describe  some  of  these  transformations; 
the  notation  means  that  constructs  of  the  form  are  transformed  into  constructs  of  the  form  C2- 


l^Thts  restriction  is  imposed  in  order  to  prevent  subtle  errors  arising  from  the  use  of  similar  identifiers  in  the 
same  scope.  Routines  ere  exemoted  from  the  restriction  in  order  to  permit  operator  overloading. 
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3.4.1  Operators 

Neither  the  syntax  nor  semantics  of  Alphard  includes  the  traditional  notion  of  arithmetic  or  boolean 
expressions  with  infix  operators.  Rather,  the  language  is  defined  as  though  all  operations  were 
expressed  as  function  invocations.  In  order  to  permit  the  user  to  write  programs  in  the  more  familiar 
infix-expression  format,  however,  two  transformations  are  performed.  First,  the  Input  text  is  fully 
parenthesized  in  order  to  observe  the  following  precedences  and  associativities: 

1.  Associativities:  The  operators  of  highest  and  lowest  precedence  are  right  associative;  the 
remainder  are  left  associative. 

2.  Precedence: 

r (highest  precedence) 

* / div  rem 

♦ - 

< < * * > i 
not 

ano  cand 
or  cor 
imp 

:*  ♦:»  «;s  etc.  (lowest  precedence) 

After  being  parenthesized,  expressions  are  converted  to  functional  form.  If  o L and  (i  denote  arbitrary 
unary  (monadic)  and  binary  (diadlc)  operators,  respectively,  then  the  following  trar  'formations  are 
performed: 

<term>1  <term>2  -*>  i^((<term>1  .tternOj) 

o£<term>  — > &oC(<term>) 

<term>1  /<:«  <term>2  -->  &:*(<term>.,,  &,a(<term>  ■]  ,<term>2)) 
where  the  <term>s  denote  any  phrases  balanced  in  parentheses. 

After  being  placed  In  functional  form,  three  of  the  relational  operators  are  rewritten  as  the  boolean 
negation  of  one  of  the  remaining  three: 

.t2)  -->  &not(&»(t1.t?)) 

«(t,.t2)  — > &not(&>(t , ,t2)) 

«(t1,t2)  -->  4not(«.<(t1.t2)) 

in  addition,  two  of  the  boolean  operators  are  rewritten  as  conditional  expressions: 
ti  cand  t2  — > if  t1  then  tg  else  false  fi 
*1  eor  *2  if  then  true  else  t2  fl 

This  rewrite  is  required  to  avoid  the  possibility  of  undefined  argument  values  in  Invocations. 

Note  that,  as  stated  earlier,  symbols  of  the  form  &<operator>  may  be  defined  by  the  user.  Thus,  by 
giving  a definition  to  the  programmer  gives  a definition  to  the  operator  this  does  not  allow 

redefinition  of  existing  operators,  but  does  allow  these  operators  to  be  extended  to  new  types. 

3.4.2  Name  Qualification  and  Subscripting 

It  is  often  convenient  to  refer  to  the  (visible)  components  of  an  object  by  symbolic  names;  for 
example,  the  components  of  a record  have  traditionally  been  named  In  this  way.  The  conventional 
syntax  allows  "X.y“  to  denote  the  y component  of  X. 
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The  syntax  of  Alphard  does  not  support  such  "dotted  name"  qualification  directly,  but  instead  uses 
the  functional  form,  y(X).  To  permit  the  dotted-name  notation  and  user-defined  subscripting,  qualified 
names  are  transformed  In  two  steps.  First,  dotted  names  are  eliminated  in  favor  of  a functional  form: 

<quatname>.<identlfier>  -->  <ldentlfier>(<qualname» 
where  <qualname>  is  any  sequence  of  Identifiers  (including  special  identifiers).  Vs,  '**s,  end 
sequences  of  lexemes  balanced  and  enclosed  in  parentheses  or  square  brackets.  The  rule  Is  applied 
rlght-to-left;  thus,  for  example 
A.y  -->  y(A) 

Q.g[s.t].f  ~>  f(g(Q)[t(s>]) 

After  all  dots  have  been  removed,  square  brackets  are  removed: 

<term)[<expres3ion  list)]  — > 8>subscript(<term), Expression  list)) 

Thus,  the  example  sb<A/e  becomes 

Q.g[s.t].f  — > f(g(Q)[t(s)])  — > f(&subscript(g(Q),t(s))) 

Note  that  the  user  may  define  the  selector  &subscript  and  hence  may  specify  the  access  algorithm  for 
a type. 

3.4.3  Automatic  Introduction  of  Semicolons 

The  effect  of  the  following  transformation  is  to  eliminate  the  need  for  explicit  semicolons  to  separate 
declarations  or  statements  when  those  semicolons  would  fall  at  the  end  of  a text  line.  According  to  the 
syntax  in  this  report,  certain  phrases  are  separated  from  each  other  by  semicolons.  In  those  cases 
where  the  final  lexeme  on  a line  could  end  such  a phrase,  e.g., 
end.  ),  fl,  esac,  fo,  ni,  od,  exltloop 

and  the  next  lexeme  (i.e.,  excluding  comments)  could  begin  such  a phrase,  e.g., 
begin.  (,  if,  case,  with,  first,  do.  for 

the  compiler  automatically  inserts  a semicoion  between  the  two  unless,  on  the  basis  of  preceding 
symbols  it  is  possible  to  determine  that  doing  so  would  render  an  otherwise  syntactically  valid  program 
into  an  Invalid  one. 


3.S.  Special  literals 


Certain  well-established  literal  denotations  exist  for  some  types  (e.g.,  integer,  real,  boolean). 
3,6.1  Syntax 


<special  literal* 
"unsigned  integer* 
<unsigned  real* 
<unsigned  rational* 
"scale-factor* 
«string> 

<boolean» 

"radix* 


<unsigned  integer*  | <un»gned  real*  | "string*  | <boolesn>  I "radix* 
("digit*}* 

"unsigned  rational*{E«scale-faetor>}*  | "unsigned  integer»E"scale-fsetor> 
"unsigned  integer*."unsigned  integer* 

{♦(.[•"unsigned  integer* 

‘"any  sequence  of  characters  with  all  quotes  doubled** 
true  I falsa 

{"eiphanumeric>)**"elphanumeric> 


3.6.2 


Examples 

3 

1 47.5E-3 
32#8 


true 
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"ABcdEF" 

"He  said,,,MHa!-“" 

3.S.3  Semantics 


<radlx>  literals  are  of  type  rawstorage.  The  <alphanumeric>  following  the  character  specifies 
the  representation  base.  The  values  of  the  alphanumerics  are  interpreted  as  follows:  0-9  denote  0-9 

A-Z  denote  10-35.  a-*  denote  36-61.  Note  that  0.  1 and  • (zero,  one  and  grave)  are  not  legal  base 
denotations.  * 
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Chaptar  4 

Program  Structura,  Expraaalons  and  Statamants 


4.1.  Program  Structura,  Blocks 

A compilation  unit  may  be  either  a block  or  a set  of  declarations.  If  It  Is  a block,  It  la  a "program"  In 
the  traditional  sense  — a stand-alone  computation.  If  it  is  a sat  of  declarations,  the  scope  of  the 
declarations  is  system-dependent. 

4.1.1  Syntax 

compilation  unit* 

<block> 

<exec  decl  list* 

<exec  dect* 


4.1.2  Semantics 

A block  specifies  a computation  whose  effect  is  as  though  the  following  order  of  execution  were 
observed: 

1 . Elaborate  the  declarations  in  the  order  given  (see  2.2  and  5.S). 

2.  Elaborate  the  statements  (<stmt>s)  in  sequence  (aside  from  exits;  see  4.9). 

3.  Destroy  the  objects  created  in  1 In  the  reverse  order  of  declaration. 

The  scope  of  all  declarations  in  a block  is  the  text  of  the  block,  where  not  superseded  by  neeted 
declarations. 


begin  <block»  end  | <exee  decl  list* 

(<exec  decl  listj;}*  {<stmt>}*  {;J* 

( <exec  decl*  );* 

<var  decl*  | const  decl*  | <proc  decl*  | <1orm  decl*  l «t»bel  deci» 


4.2.  Expressions  and  Statements 

Expressions  and  statements'designate  actions  to  be  performed.  Their  elaboration  results  in  changes 
in  the  execution  state  of  the  program.  Expressions  differ  from  statements  only  In  that  their  elaboration 
may  "produce  values”  as  well  as  performing  other  actions;  statements  only  perform  actions.  For 
definitional  brevity  and  convenience,  every  expression  is  considered  td  be  a statement,  but  not 
conversely.  When  an  expression  is  used  in  a context  requiring  a statement,  its  "value"  is  discarded. 

Somewhat  more  precisely,  the  "value  produced  by  an  expression"  Is  an  object  resulting  from  Its 
elaboration;  the  type  of  this  object  is  uniquely  determined  by  the  rules  stated  in  the  remainder  of  this 
chapter.  This  resulting  (unnamed)  object  exists  until  any  immediately  enclosing  expression  or 
statement  that  uses  it  has  finished  execution. 
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4.2.1  Syntax 

<expresston> 

<stml> 

^labeled  stmt> 


<invocation>  | <condition»l  expression*  | <value  expression*  | 
<with  expression*  | <lirst  expression* 

<expression>  | <loop  stmt*  | <exit  stmt*  | <null  stmt*  | 
<inner  block.*  | <labelsd  stmt*  j <assert  stmt* 

<identifier>  : «stmt> 


4.2.2  Semantics 

Statement  labels  are  used  by  exit  statements  (section  4.9).  The  effect  of  an  exit 
statement  is  to  force  control  to  the  point  Immediately  following  the  labeled  statement  whose  label  Is 
used  in  the  exit.  Labels  must  be  declared  (see  section  5.4)  and  may  be  used  to  label  only 
one  statement  within  the  scope  of  their  declaration. 


4.3.  Invocations 


4.3.1  Syntax 

<invocation> 

< actuals* 

<actual> 

<simple  invocation* 


<special  literal*  ( <simpte  invocation^xactuals*)*  1 (<invocation>) 
(factual*),*) 

<axprassion*  | <type  description* 

[<identifier*l  }*  <.dentilier»  | <special  identifier* 


Infix  and  prefix  operators  fall  under  this  syntax  by  the  rewrites  of  section  3.4.1.  Subscripting, 
denoted  by  falls  undar  this  syntax  by  the  rewrites  of  section  3.4.2.  Note:  <special  identifiers 

may  not  appear  in  source  programs;  they  result  only  from  these  rewrites. 


4.3.2  Examples 

The  most  obvious  <invocatlon>s  are  those  denoting  routine  'calls",  e.g.: 
sln(x) 

Integrated, a, b.eps) 

In  addition,  however,  {invocations)  result  from  the  rewrite  rules  for  infix  operators  and  subscripting, 
e.g.: 

&:>(a,  &«(b,c)) 

&:*(x,  Ssubscript(V.i)) 

Finally,  {invocations  occur  as  part  of  type  descriptions: 
vector(int,  1 ,unk) 

4.3.3  Semantics 

A simple  Invocation  may  designate  a type,  an  object,  or  a routine  (a  procedure  or  selector)  as 
indicated  In  chapter  5.  Identifiers  may  deaignate  multiple  entitles  In  any  given  context 
(operator  overloading),  so  some  means  of  resolving  the  conflict  Is  necessary.  An  identifier  may  be 
qualified  on  the  left  by  the  name  of  the  form  containing  its  definition;  such  qualifiers  are  separated  by 
"S".  Alternatively,  the  proper  definition  may  be  determined  by  examining  the  types  of  the  actuals  — 
that  is.  by  choosing  that  definition  for  which  type  chtjking  (section  2.4)  succeeds.  It  Is  an  error  If  the 
compiler  cannot  disambiguate  statically  (i.e.,  at  compile-time). 

Assuming  that  the  entity  designated  by  G Is  uniquely  determined,  an  Invocation  such  as: 

*n> 

denotes  an  elaboration  and  possibly  a resulting  value  as  follows: 
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1.  The  actual  parameters,  S|.  are  elaborated  in  an  undefined  order.  An  S|  designating  a routine 
without  an  argument  list  designates  that  routine,  rather  than  the  value  resulting  from  Its 
execution.  The  results  of  this  elaboration  are  objects,  types,  and  routines  (see  section 
5.0  for  the  evaluation  of  partial  types). 

2.  The  number  of  formal  parameters  of  G must  be  n (n20).  The  actuals  must  match  the  formats 
of  G (see  section  2.4);  it  is  an  error  if  they  do  not. 

3.  Each  formal  parameter  of  G which  designates  a routine  (as  in  "f:groc(...)"),  a type  (as  in 
MT:form“),  or  a reference  parameter  (as  in  "var  x:..."  or  "const  x:...")  Is  bound  to  the 
corresponding  S|  (also  see  section  5.7). 

4.  Each  object  formal  (see  S.7)  with  an  empty  <binding>  Is  treated  as  If  It  were 
specified  const  (see  below). 

5.  For  each  formal  identifier,  k,  designated  to  be  a const  parameter  (see  section  5.7), 
Update(k)  Is  made  empty.  For  ail  other  k bound  to  objects,  Update(k)  Is  derived  from  the 
type  description  of  the  formal  parameter. 

8.  -ar  and  const  parameters  are  checked  for  possible  overlap  (see  section  2.1).  In  order  for 
thw  <invocation>  to  be  legal  it  is  necessary  that  either 

there  Is  no  overlap  between  an  actual  parameter  that  stands  in  a var  position  and  any 
other  actual  in  either  a var  or  const  position, 
or 

ail  overlapping  positions  are  designated  alias  in  the  formal  parameter  specifications. 

7.  For  each  formal  identifier,  k,  designated  to  be  a copied  parameter,  a new  object  of  the  same 
type  Is  Instantiated.  The  values  of  the  actual  parameters  (see  sections  5.6  and 
5.7)  are  copied  Into  these  variables  from  the  corresponding  ef  using  the 
procedure  defined  for  that  type;  It  is  an  error  if  the  "&:■*  procedure  is  not  defined  for  the 
type. 

8.  If  G Is  a routine  and  returns  a value,  or  if  It  is  a selector  (see  section  5.8),  Its 
definition  contains  a type  description  which  specifies  the  type  of  Its  result.  This  description 
Is  elaborated.  If  G is  a vproc  or  func.  an  object  of  the  type  is  Instantiated  to  receive  the 
"value"  that  will  be  returned.  If  G is  a salector  no  object  is  Instantiated;  the  type 
description  defines  the  type  of  the  object  whose  (generalized)  address  is  returned.  Note 
that  a vproc  or  func  must  specify  a full  type  for  the  result;  a sel  need  only  specify  a partial 
type. 

0.  If  G is  a routine  its  body  is  elaborated  with  the  established  bindings.  If  G Is  a type 
description  either  an  instantiation  or  a matching  is  performed,  depending  on  the  context. 

1 0.  Any  auxiliary  objects  (l.a.,  copied  parameters  or  actuals  which  are  themselves  result 
objects  of  procedures)  are  deallocated. 

It  should  be  noted  that,  by  the  rules  above,  the  Invocation  of  a parameterless  procedure,  P,  is 
necessarily  written  "PO". 
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4.4.1  Syntax 


conditional  expression* 
<if  expression* 

Casa  expression* 
Case* 


<if  expression*  | Ca»#  expression* 

i£  <expression»  then  'block*  { j|if  expression*  then  <bloch*  ]*  (else  'block*)"  fi. 
case  expression*  gf  case*  { slot  Case*  )*  { else  «bloch>  }•  esac 
(expression*),  s 'blocs* 


4.4.2  Examples 

If  a[l]>mox  then  maxp  :*  I;  max  :*  a[l]  fl 
y :■  if  x>z  then  x else  z fl 

if  a<b  then  t :■  1 el]t  a<c  than  t :■  2 else  t :■  3 fl 
case  1C  of 

ADO::  MB  :■  C[EA];  R :■  fl»MB  elof 
SUB::  MB  :«  C[EA];  H :*  R-MB  elof 
MUL::  MB  ;e  C[EA]j  R :■  R'MB  else 
ERROR 

esac 

T :■  case  n of  1 ::MALE  elof  2::FEMALE  else  NEUTER  esac 


4.4.3  Semantics 


Conditional  expressions  denote  expressions  and  statements  to  be  evaluated  conditionally.  Such  an 
expression  has  a value  If 

a.  All  <block>s  In  it  are  single  expressions, 

b.  All  these  expressions  are  of  Identical  type  (this  type  becomes  the  type  of  the  expression), 
and 

c.  An  else  clause  is  present. 

The  expression 

If  Bi  then  S1  ellf  B2  then  S2  ...  elif  8n  then  Sn  else  Sn<l1  fl 
Is  equivalent  to 

If  Bi  then  S1  else 
If  B2  then  S2  else 

If  Bn  then  Sn  else  Sn+1  ft 


fl 

fl 

In  the  expression 

if  B then  S1  else  S2  fl 

B must  have  a result  of  type  boolean,  and  the  elaboration  of  B must  not  have  observable  effects.  If 
the  value  of  B is  true,  Sj  Is  evaluated,  otherwise  S2  is  evaluated.  If  the  if  expression  occurs  in  a 
context  requiring  a value,  the  value  is  that  of  the  expression  chosen  (by  the  rules  above,  S1  and  S2 
must  be  simple  expressions  of  the  same  type).  In  the  absence  of  an  else  clausa,  S2  Is  taken  to  be 
skip  (see  section  4.10). 


■ 
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In  the  expression 
case  E0  of 

Ei  j,  ...  Ei,,^  ::  S1  elof 
E21-  - E2n2  !!  S2  5!°! 

Em1 ^mn_  ::  *ls* 

sm*i 

•sac 

E0>  E1 1 Emnm  n,U3t  311  b«  expressions  of  the  same  type.  E0  is  evaluated.  The  E(j  are  evaluated  (In 

unspecified  order)  and  the  results  are  compared  with  E0  using  the  *■  operator  for  Type  (Eg).  It  mn 
error  If  there  is  no  such  operator.  The  evaluation  of  Eg  and  the  E(j’s  must  not  have  observable  effects. 
As  soon  as  a match  yields  true  (say  with  Ejj),  S|  Is  evaluated.  If  all  matches  fail,  Sm+^  is  evaluated. 
Exactly  one  block  S|  is  evaluated  for  each  correct  evaluation  of  the  case  expression.  The  value  of  the 
c*ee  expression  is  that  of  the  S|  evaluated  (again,  each  Sj  must  be  a single  expression). 

4.5.  Value  Expression 

4.5.1  Syntax 

<value  expression*  value  <identifiar>{r<ob)  type*)*  gf  <bloek»  fg 

4.5.2  Examples 

S :•  value  ytint  of  y:«0;  for  x:invec(A)  do  y:»y*x  od  fo 
value  A of  Munge(A,43)  fo 

4.5.3  Semantics 

A value  expression  is  used  to  convert  a <btock>,  and  hence  a sequence  of  declarations  and 
statements,  into  a (value-yielding)  expression.  In  the  expression 
value  x:T  of  S fo 

the  variable  x (whose  scope  is  S)  la  inatantlated  and  S ia  executed.  If  ":<obJ  type>*  is  omitted,  as  In 
value  x of  S fo 

the  existing  Instantiation  of  x is  used.  In  both  eases,  the  result  of  the  value  expression  ia  the  object 
Obj(x). 

4.6.  With  Expressions 
4.6.1  Syntax 

<with  expression*  with  <with  list*  ifl  <bloek>  ni 

<with  list*  { <idenlifiar>r<invocation>  ), 


4.5.2  Examples 

with  2:A[l].son[k]  In  Z.age  :»  0;  Z. number  :■  k nl 
with  R-.x.y.z,  Q:x.y.w  in  var  s:T;  a :■  Q;  0 :■  R;  R :■  a ni 


I 
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4.0.3  Semantic* 

A with  expression  provides  a local  shorthand  for  complicated  invocations.  The  phrase 
with  x:R  in  S ni 

causes  elaboration  of  R,  binding  of  x to  R,  end  elaboration  of  S with  that  binding.  If  the  <block>  is  a 
single  expression,  the  with  expression  yields  a value  (the  value  of  the  <block>). 


4.7.  First  Expression 


4.7.1  Syntax 

<first  expression*  first  template*  suehthit  ^expression*  ilhen<block>)*  lelsa  <block>}*  fi, 

<template»  <identifier>  from  {<identifier»:)*<typa  description*  | <identifier»  from  <invocation» 


4.7.2  Examples 

first  i from  upto(  1 ,n)  suchthat  A[i]>max  then  max  :■  A[i];  jmax  :■  I fl 
y :■  first  x from  mvec(A)  suchthat  x>max  then  x else  0 fl 

4.7.3  Semantics 

The  first  expression  invokes  the  generator  specified  in  its  template  (see  section  5.11)  to 
produce  a sequence  of  values.  These  values  are  tested  in  turn  by  the  suchthat  clause,  which  must  be 
a boolean  expression  and  which  may  not  have  observable  side  effects.  If  the  first  expression 
first  x from  g:Q  suenthat  8 then  else  S2  fl 

occurs  In  a context  where  a value  is  not  required,  its  semantics  are  precisely  those  of  the  statement 
LI : begin 

12:  begin 

var  g:0;  istart(g); 
do 

if  &done(g)  then  &finish(g);  leave  L2  fi 
with  x:Avalue(g)  in  if  B then  -,&finish(g);  leave  LI  fl  nl 
&next(g) 
od 

end  L2 
S2 

end  LI 

where  &start.  Adone,  etc.  are  provided  by  the  form  (or  generator)  Q (see  also  sections  4.8 
and  4.9).  If  either  the  then  or  the  else  clause  is  absent,  it  defaults  to  skip  (see  section 
4.10).  If  "g:"  is  absent,  an  elsewhere  unused  identifier  is  substituted  by  the  compiler.  If  the 
full  type  in  the  template  Is  absent,  the  declaration  (var  g:Q)  Is  omitted;  In  such  cases  an  existing 
Instantiation  (namely  "g")  is  used. 

Note  that  the  statement  S2  in  the  expansion  above  is  outside  the  scope  of  the  declarations  of  g and 
x;  neither  of  these  may  be  referenced  in  S2. 

If  the  first  expression  occurs  in  a context  requiring  a value,  and  S2  must  both  be  present  and  be 
single  expressions  of  identical  type  (say  T).  In  these  contexts,  the  semantics  are  precisely  those  of 
value  t:T  of  first  x from  g:Q  suchthat  B then  t:»  S-j  else  t:«S2  fl  fo 
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4.8.  Loop  Statement* 


4.8.1  Syntax 

-simple  loop*  1 <whij#  stmt*  | «for  stmt* 
do  ' block*  od 

while  -expression*  -simple  loop* 
tor  -template*  -simple  loop* 


-simple  loop* 
-while  stmt* 
-for  stmt* 


4.8.2  Examples 
do 

if  x*y  then  exitloop  fi 
if  x>y  then  x :■  x-y  else  y :«  y-x  f| 
od 


while  x^nil  do  P(caKx));  x • cdr(x)  od 


for  x from  invec(a)  do  x ;■  0 od 
4.8.3  Semantics 


Th*  lQOPl  "32  S od-,  executes  S repeatedly,  it  will  terminate  only  if  an  exit  command  (sea 

section  4.9)  is  executed.  The  while  loop,  -while  3 do  S od-,  is  semantically  equivalent  to 
do  if  not(B)  then  exitloop  fi,  S od 

The  for  loop,  “for  x from  g:Q  do  S od",  is  semantically  equivalent  to 
begin 

ver  g:Q;  istart(g) 
do 

If  &done(g)  then  exitloop  ft 
with  x:  &value(g)  in  S nl 
&next(g) 


od 

iflniah(g) 

end 


As  in  the  first  express, on  (section  4.7),  if  -g:-  is  absent,  an  elaewh.re-unuaed  identifier  is  substituted 
by  the  compiler.  If  the  full  type  in  the  template  is  absent,  the  declaration  (ver  g,Q)  Is  omitted  and  an 
existing  instantiation  Is  used. 


4.9.  Exit  Statements 


4.9.1  Syntax 
-exit  stmt* 


exitloop  | i«»ya  -identifier* 


4.9.2  Examples 
leave  L 

exitloop 


See  also  sections  4.0  and  4.7. 
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4.9.3  Semantics 

The  statement  "leave  L*  occuring  within  a statement  labeled  "L"  (or  a routine  named  "L")  causes 
evaluation  of  the  innermost  such  statement  (routine)  to  terminate;  execution  resumes  at  the  point  it 
would  have  if  the  statement  (routine)  had  terminated  normally.  (Note:  if  the  relative  nesting  of  the 
labeled  statement  Is  such  that,  had  the  leave  not  bean  executed,  objects  would  have  been 
deallocated  and  final  clauses  executed,  these  same  deallocation  actions  and  finalizations  are 
performed  in  the  same  order  as  part  of  the  leave.) 

An  exitloop  causes  termination  of  the  innermost  loop  statement  (do,  while,  or  for,  section  4.0) 
containing  the  exitloop.  — 


4.  1 0.  Null  Statement 

4.10.1  Syntax 

<null  stmt>  skip 

4.10.2  Semantics 

The  null  statement  does  nothing. 

4.11.  Inner  block 

4.11.1  Syntax 

<inner  block*  begin  <block>  jng  | begin  <bloek>  endol  (^identifier*)* 

4. 1 1 .2  Semantics 

The  declarations  and  statements  of  the  block  are  executed  as  given  In  section  4.1.  If  the  optional 
identifier  la  present.  It  must  match  the  label  of  the  inner  block  or  the  name  of  the  routine  whoae  body  is 
the  Inner  block. 


4.12.  Assert  Statement 
4.12.1  Syntax 

<a*«ert  stmt*  mart  <essertion* 


4.12.2  Examples 

do  assert  (GCO(x.y)  » GCD(sO.yO)  >; 
if  x»y  then  exitloop  fi 
if  x>y  then  x y else  y x fl 


od 
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4.12.3  Semantics 

An  assart  statement  indicates  a condition  that  must  be  true  when  control  passes  through  the 
statement.  It  has  no  semantic  effect  The  syntax  of  <assertlon>  Is  not  specified  by  the  language 
(other  than  that  the  assertion  text  must  be  enclosed  in,  and  balanced  in  brackets,  It  Is  the 

province  of  a verifier  or  verifying  compiler  only. 
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Chapter  S 
Declarations 


Declarations  define  routines  (proc.  vproc,  func.  and  sal  declarations)  and  classes  of  types  (form 
declarations),  specify  the  Instantiation  of  objects  (var,  const),  and  bind  Identifiers  to  these  entitles. 


5^1 . Scope  of  Declarations 

The  scope  of  a declaration  — the  program  text  In  which  the  binding  it  establishes  is  valid  --  depends 
on  the  kind  of  declaration  and  the  place  it  appears.  In  the  sequel,  normal  Algol  scope  means  the 
innermost  block  containing  the  declaration,  including  all  blocks  it  encloses  that  do  not  redefine  the 
identifier.  Restricted  Algol  scope  Is  the  same  as  normal  Algol  scope,  but  excludes  the  text  of  routine 
and  form  declarations. 

Generally  identifiers  naming  routines  and  forms  obey  Algol  scope  rules;  identifiers  naming  objects 
(l.e.,  variable  names)  obey  restricted  Algol  scope.  Thus,  no  free  variable  names  appear  In  routine  or 
form  bodies;  all  variables  are  either  locally  declared  or  passed  In  through  the  parameter  list.  A few 
additional  scope  restrictions  are  discussed  later. 


5.2.  Auxiliary  Declarations 

Any  declaration  may  be  preceded  by  the  keyword  aux.  Identifiers  defined  In  such  declarations  may 
not  be  used  (except  within  the  assertion  language).  Auxiliary  declarations  serve  as  modeling  tools  in 
the  specifications;  the  entities  described  by  such  declarations  may  or  may  not  exist  in  the 
implementation.  If  such  entitles  do  exist,  they  may  be  implemented  in  a manner  different  from  that 
described  in  the  aux  declaration.  (Note,  however,  that  the  clause  as  specified  may  be  used  in  an 
implementation  to  force  precisely  the  representation  appearing  In  an  aux  definition  of  an  entity). 

An  auxiliary  declaration  of  a boolean-valued  function,  for  example,  might  be  conveniently  used  to 
express  a condition  that  is  useful  for  verification  or  specification  purposes.  No  obligation  to  actually 
Implement  this  function  (whose  implementation  might  be  undesirable  or  impractical  In  some 
environments)  is  implied  by  the  aux  declaration.  Consider,  for  example,  the  form: 
form  OirectedGraph(size;int)  is 
specs 

aux  func  lsTree(g:OirectedGraph);boolean 
post  { returns  true  iff  g Is  a tree  }; 

end  OlrectedGraph; 

This  form  provides  the  predicate  "IsTree*  which  tests  an  arbitrary  directed  graph  for  treeneas;  since 
the  predicate  is  specified  aux  it  can  only  be  used  in  specifications,  not  In  code. 


5.3.  Remote  Definitions 
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Occasionally  the  detailed  Implementation  of  an  entity  (variable,  routine,  or  form)  may  appear  at  a 
point  remote  from  its  declaration.  The  following  important  cases  arise: 

1.  forward:  It  may  be  necessary  to  mention  en  entity  before  is  defined;  this  is  logically 
necessary  In  mutually  recursive  routine  and  form  definitions.  A forward  Indicates  that  the 
required  definition  appears  later  in  the  current  program  text. 

2.  as  specified:  In  the  implementation  of  a form  it  may  be  desirable  to  define  an  implementation 
of  an  entity  to  be  identical  to  Its  specification;  such  definitions  are  denoted  as  specified. 
Somewhat  similarly,  a form  implementation  may  mention  an  (object)  parameter  of  the  form, 
describing  It  as  specified,  to  denote  that  a run-time  representation  of  the  parameter  is  to 
exist. 

3.  external! <system  specs>):  The  definition  of  some  entitles  may  be  defined  external  to  the 
present  program  text,  e.g.,  on  a "file"  or  a "library"  supported  by  the  host  system.  In  such 
cases  the  entity  may  be  defined  as  external.  The  <system  specs>  is  a system-dependent 
notion  (and  syntax)  that  describes  the  place  where  the  definition  Is  to  be  found  (e.g.,  in  a 
particular  "file"). 


5.4.  Label  Declarations 

8.4.1  Syntax 

<label  decl>  s-  libel  <identtfier  liat» 


5.4.2  Examples 

label  LI,  EXIT,  Rethink; 

5.4.3  Semantics 

Labels,  like  all  other  Identifiers,  must  be  declared  before  use.  A label  may  be  "placed"  (uaed  to  label 
a statement)  only  once  in  the  scope  of  its  declaration. 


5.5.  Object  Declarations 
5.5.1  Syntax 

• e e • a • 

"ver  dec'* 

"const  decl> 

«au*» 

<ob)  dec!  grouo> 

«ob)  lype» 

"init  fin  clause* 

<const  assign* 


<«ux»  v»r  (<otjj  dec'  group»{«mi|  fin  clause*}*),* 

<au*>  const  |*ob/  decl  group*  («n«t  fin  clause*}*  | "const  assign*},* 

laso)“ 

<identifier  list*  : <ob|  type* 

"type  description*  I |g  specified 
• <e»pression»  | (.r>ii<stmt>)"  (final  "stmt*)* 

"identifier  list*  • "expression* 
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6.5.2  Examples 

var  a.b,c:int,  g:raal 
aux  const  a:lnt  • 5 

var  INF:file( vector*  mumble,  1 , unit))  init  open(INF) 
var  q.x.rias  specified 
var  Q:quoua(int)  init  new(Q)  final  dastroy(Q) 
conat  A00«0,  SUB»1 , MULT*  2 

6.6.3  Semantics 

Object  declarations  may  occur  inside  form  declarations  or  in  blocks;  their  meanings  in  the  two 
contexts  differ.  See  section  5.9  for  a discussion  of  their  meanings  in  form  declarations. 

In  blocks,  object  declarations  have  restricted  Algol  scope  (see  section  5.1).  Semantically,  constant 
declarations  (<const  decDs)  differ  from  variable  declarations  (<var  dect>s)  only  in  that,  outside  the 
initialization  and  finalization  clauses,  'ipdate(c)  is  empty  for  c a constant;  for  variables  the  update  set 
Is  determined  from  the  <type  description). 

The  <obj  decl  group>s  within  an  object  declaration  are  processed  In  unspecified  order  (note, 
however,  that  declarations  are  processed  in  left-to-right  order;  thus  the  programmer  may  impose  an 
ordering  If  that  is  appropriate).  For  each  group,  the  full  type  Is  evaluated,  and  for  each  Identifier,  a 
new  object  of  that  type  is  Instantiated  and  bound  to  the  identifier.  If  an  Init  clause  is  present.  It  is 
executed.  The  declaration 
. . .x,y,z:T«E 
is  equivalent  to 

. . .X,y,Z:T  init  X:«y:»Z:*E 

If  ":T"  Is  absent  (from  a constant  declaration),  as  in  "const  a»5",  the  type  is  thet  of  the  expression  to 
the  right  of  the  equal  sign. 

A flnaj  clause,  if  present,  is  executed  just  before  deallocation  of  the  vaneblea  or  constants  with 
which  it  is  associated.  Deallocation  is  always  in  reverse  of  the  (possibly  unspecified)  order  of 
creation. 

Objects  may  be  designated  "as  specified"  only  in  form  implementations  (section  5.9).  This 
Indicates  that  the  <type  description)  is  to  be  copied  from  the  form  specifications. 

An  <inft  fin  clause)  in  a constant  declaration  can  be  omitted  only  in  the  specifications  pert  of  a form 
(see  section  5.9). 


S.6.  Evaluation  of  Type  Descriptions 

<type  description^  are  syntactic  entities  which  appear  in  object  declarations  and  formal  parameter 
specifications. 
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5.S.1  Syntax 


<typa  description* 
<formal  qual* 
<updata  set* 


<$impl#  invocation*  { ( {<formal  dual*]*  ) }•  {<update  cat*]*  | 

?<identifier*{<update  set*}" 

<e*pression>  | ?<idanti(iar*{<updata  set*}*  | !<identifier>:)"  <typa  daacription*  | 
unk 

< { <idantitiar>  | <>pacial  identifier*  },*  > 


Note  that  the  outer  O’a  In  the  definition  of  <update  set>  are  part  of  the  language,  not  metabracketa 
(see  examples  below). 


5.6.2  Examples 
Integer 

vector(real,1,10) 
stack(T:form<4:0,22) 
collectlon(unk) 
queue(  process. ?!ength) 

5.6.3  Semantics 


The  <simple  invocation)  (see  4.3)  must  designate  a unique  form  ("S"  qualification  allows  duplicate 
nested  form  definitions).  Disambiguation  on  the  basis  of  argument  types  Is  not  performed. 

Elaboration  of  a <type  description),  T(e;  ,...,en)<Pi  ,...,pm>,  proceeds  as  follows13  : 

1.  The  e(  are  elaborated  in  an  undefined  order.  The  results  of  this  elaboration  are  objects, 
routines,  and  types.  The  following  special  cases  should  be  noted: 

a.  The  elaboration  of  unk  is  unk. 

b.  The  elaboration  of  Tldentlfiers  implies  an  implicit  binding;  it  la  illegal  if  this  is  not  In 
the  context  of  a formal/actual  parameter  matching. 

2.  The  number  of  formal  parameters  of  T must  be  n (niO).  The  actuals  must  match  the  formats 
of  T (see  section  2.4).  It  is  an  error  If  they  do  not 

3.  Each  object  actual  la  handled  as  In  section  4.3.3. 

4.  The  sequence  of  routines,  types,  objects,  and  unk  markers  produced  by  the  preceding 
becomes  the  Qual  property  of  the  result  type.  T la  the  Base  type  (see  section  2.2).  The  p( 
become  the  update  set. 

The  < update  set)  defines  the  update  set  of  the  type  description  (see  2.2).  The  listed  Identifiers 
must  be  names  of  routines  declared  with  the  base  type.  Only  these  routines  and  routines  with  no  visible 
effects  may  be  applied  to  the  object  within  the  scope  covered  by  the  declaration  in  which  the  type 
description  appears.  In  the  case  that  the  update  sat  is  attached  to  a Tldentlfler  or  a <type  formal), 
the  listed  identifiers  must  be  further  specified  in  an  ’assumes  clause*  (see  5.12)  un/ess  they 


13Note  that  an  implementation  may  require  compile-time  elaboration  of  those  type  descriptions  used  as  formal 
parameter  specifications. 
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are  <apecial  identifier^  such  as  "&»*.  The  assumptions  about  <speciai  identifier>s  are  uniform  and 
are  included  in  appendix  C.  If  no  (update  set>  is  given  It  is  assumed  to  contain  the  full 
update  set  of  the  type;  the  (update  set>  "(>"  denote  the  empty  set. 


5.7.  Formal  Parameters 

Certain  entities  --  forms  and  routines  --  can  be  parameterized.  Formal  parameters  specify  these 
parameterlzations.  The  process  of  determining  whether  a given  sequence  of  actuals  conforms  to  the 
sequence  of  formal  parameters  Is  known  as  matching  or  type  checking.  This  process  binds  actual 
parameters  to  the  corresponding  formal  parameters.  It  may  also  cause  certain  Implicit  bindings  of 
identifiers  marked  with  a "?"  lexeme  In  the  formals;  these  Identifiers  are  implicit  parameters  with  the 
same  scope  as  ordinary  formals.  The  implicit  bindings  are  in  effect  whenever  the  explicit  bindings  of 
ordinary  formals  are. 

The  scope  of  a formal  parameter  to  a routine  is  the  text  of  the  parameterized  declaration,  In  the 
"restricted  Algol  scope"  sense.  That  is,  the  scope  of  a formal  does  not  include  routine  or  form 
declarations  within  the  parameterized  routine  text. 

The  scope  of  a formal  parameter  to  a form  is  at  most  the  text  of  the  parameterized  form  declaration: 
it  is  also  subject  to  "restricted  Algol  scope".  In  addition,  unless  explicitly  redeclared  In  the  Impl 
(specifically,  redeclared  as  specified),  the  scope  of  form  formals  is  limited  to  the  specifications  and 
object  declarations  (Including  init  clauses)  of  the  form  other  than  shared  objects. 

5.7.1  Syntax 

<formals> 

<rouhne  formal* 

<binding> 

<formal  id  list* 

<obj  formal* 

<type  formal* 


5.7.2  Examples 

(const  x:T1,  var  q:?T2.  copy  r:vector(?T2,1.n)) 

(T:form,  h:proc(x:real):int) 

5.7.3  Semantics 

Formal  parameters  give  the  specifications  of  allowable  actual  parameters  and  provide  local  names  for 
these  parameters.  A (routine  formal>  indicates  a parameter  position  to  be  filled  with  a procedure  or 
selector.  A (type  formal)  indicates  a position  to  be  filled  by  a type  description.  An  (obj  formal) 
Indicates  a position  to  be  filled  by  an  object.  The  association  of  actual  parameters  to  formals  is 
determined  positionally. 

The  specification  of  an  object  parameter  may  be  preceded  by  a qualifier  that  controls  the  binding  of 
actual  to  formal;  the  possible  qualifiers  are  copy,  const,  var.  and  alias.  The  qualifiers  const  and  var 
denote  "by  reference"  parameters;  in  both  cases  the  parameter  name  is  bound  to  the  actual  parameter 
object,  const  parameters  (like  names  declared  in  const  object  declarations),  have  an  empty  update 
set.  As  specified  in  section  4.3,  the  qualifier  copy  indicates  that  a local  object  is  to  be  Instantiated 


( {<routine  formil*  | <bindingxobj  formal*  | <type  formal*}*  ) 

<formal  id  list*  proc  <parm«>  | <formal  id  lift*  fvoroc  | func  | sei)<v  parma* 
( copy  I ) alias)*!  const  | vjrJ  }* 

<identifier  list*  : 

<formal  id  list*  <type  description* 

<formal  id  list*  { form  | nform  }{<updat#  set*}* 
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•nd  initialized  from  the  actual  by  copying  using  the  4:*  operation  defined  for  the  type.  The  update  set 
of  copied  parameters  Is  set  to  empty,  henca  they  may  be  used  only  for  Input.  The  qualifier  alias  has  no 
semantic  effect.  It  indlcstes  that  a reference  parameter  may  overlap  other  reference  parameters; 
unless  the  alias  qualifier  Is  present,  overlapping  reference  parameters  are  prohibited. 

For  type  formals  the  actual  type  description  must  be  a full  type  If  the  formal  la  specified  as  a form.  It 
may  be  a full  or  partial  type  if  the  formal  is  specified  as  a pform. 

If  no  < binding)  Is  specified,  const  is  assumed.  It  should  be  noted  that  for  routine  parameters  not 
qualified  by  alias,  the  compiler  assumes  that  the  semantics  of  const  and  copy  are  identical^4  — hence 
the  compiler  is  free  to  copy  const  parameters  if  it  seems  desirable  to  do  so.  This  statement  Is  not  true 
for  forms  or  in  the  presence  of  alias,  and  the  optimization  may  not  be  performed  in  those  cases. 

The  notation 
a,b,c:T 
Is  short  for 

a:T,  b:T,  c:T 

Identifiers  preceded  by  *?"  are  implicit  formals.  One  binding  Is  established  for  the  identifier  during 
matching,  no  matter  how  often  it  appears.  It  is  an  error  if  it  is  not  possible  to  establish  such  a binding. 
All  instances  of  the  identifier  inside  a given  <formals>  list  must  be  preceded  by  “?*. 


5.8.  Routine  Declarations 


Routines  encapsulate  computations.  A routine  (proc,  vproc,  func)  may  or  may  not  return  a result 
object.  If  it  does,  the  update  set  of  the  compiler-generated  name  bound  to  the  returned  object  is 
always  null;  there  can  be  no  effects  on  a procedure  result.  A selector  always  has  a result  and  must 
not  have  effects;  unless  explicitly  restricted,  the  <updata  set)  of  a selector  result  Is  the  full  update 
set  of  the  base  type.  Except  within  form  specifications  (section  5.9),  routine  declarations 
have  normal  Algol  scope. 


5.3.1  Syntax 

<routine  dec!> 
<vproc  decl> 

<proe  decl> 

"set  deel> 
<routine  id> 
<parms» 

<v  parms> 

<pra» 

<pre  po*t> 
"routine  body> 


<vproc  decl*  | <proe  d#cl>  I <*al  deel> 

"au*>  (inline!*  {vproc  I func !<routine  id*  <v  parm*>  <pre  post*  "assumes* 

{<routine  body*)* 

<ju*>  (inline!*  proc  <routine  id*  <p*rm»>  <pre  poet*  "assumes*  ("routine  body*)* 
"eux*  (inline!*  sel"routine  idxv  perm**  «pre  poet*  "assumes*  ("routine  body*}* 
"identifier*  | "special  identifier* 

("formats*  )* 

("formats*  )*r"fyp#  description* 

(pre  "assertion*;)* 

"pre*  (post  "assertion*, )• 

!i  "stmt*  | t£  jj  specked  | £ forwe.  d ( a asternal  ("system  specs*) 


This  assumption  is  valid  only  so  long  as  user-defined  assignment  operators,  *&:«*,  preserve  the  intended 
meaning.  The  compiler  cannot  enforce  the  correctness  of  any  user-defined  operation,  and  specifically  not  that  of 
Thus  there  is  an  additional  verification  condition  on  the  definition  of  each  4;-  to  ensure  the  necessary 
properties. 
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5.0.2  Examples 

vproc  f(x:int):real 

pro  {abs(x)<maxintreal}; 

Is  float(x); 

inline  sel  tnang(var  A:vector(?T,1,?n),  i,J:int):T 
Is  A[i"(l-1)  div  2*j] 
proc  empty  Is  as  specified 

5.8.3  Semantics 

Selectors  (declared  sel)  name  objects.  Procedures  (declared  proc)  produce  effects  but  do  not 
return  values.  Value-returning  procedures  (declared  vproc).  may  produce  effects  and  also  return 
values  (actually  objects).  Functions  (declared  func)  are  semantically  equivalent  to  vproc's  except  that 
they  are  deterministic1^  and  do  not  have  observable  effects  on  their  parameters.  The  <stmt>  portion 
of  the  {routine  body>  of  a vproc  or  func  must  be  a single  expression  of  the  type  returned  by  the 
routine. 

The  qualifier  inline  has  no  semantic  effect.  It  indicates  that  the  compiler  should  make  the  declared 
routine  “open"  — i.e.,  produce  a copy  of  the  object  code  at  each  invocation  site. 

The  pre  and  post  clauses  have  no  semantic  effect,  but  are  specifications  of  the  routine's  behavior. 
The  pre  clause  gives  conditions  which  will  be  true  at  entry;  post  gives  conditions  at  routine  exit  (the 
keyword  result  is  conventionally  used  In  post  conditions  to  specify  the  value  returned). 

The  routine  body  may  be  absent  only  in  form  specifications  (see  5.9).  It  may  be  given  "as 
specified"  only  In  form  implementations;  this  indicates  that  the  body  Is  to  be  carried  down  from  the 
specifications.  The  routine  body  may  be  specified  as  forward  if  Its  declaration  appears  later  in  the 
same  <block>.  The  body  may  be  specified  as  external  if  the  text  of  the  definition  Is  to  be  found  In  the 
system-dependent  entity  specified  by  <system  specs). 

The  formal  parameter  lists  and  result  types  must  be  omitted  In  form  implementations  If  the  same 
routine  (name)  is  declared  in  the  specifications  of  the  form.  They  are  copied  from  the  declaration  of 
the  routine  in  the  specifications. 

The  assumes  clause  (see  section  5.12)  declares  generic  parameters  (implicit  and  explicit). 
Throughout  the  text  of  the  routine  declaration,  only  those  properties  declared  in  the  assumes  clause 
are  used  In  testing  syntactic  and  semantic  validity. 

As  stated  previously,  identifiers  that  name  objects  observe  restricted  Algol  scope.  Thus,  the  body  of 
a routine  cannot  access  objects  declared  outside  itself  unless  they  are  passed  through  the  parameter 
list.  Also,  as  stated  previously,  the  objects  named  by  distinct  formal  parameter  names  cannot  overlap 
unless  they  are  explicitly  qualified  with  alias. 


That  is,  invocations  with  equal  inputs  yield  equal  outputs.  More  precisely,  for  F to  be  s tunc.  &-(A,3)  must 
imply  S«KF(A),F(B)).-  If  & - is  not  defined,  invocations  with  identical  inputs  must  have  identical  outputs. 


3.9.  form  Declaration* 
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Forms  define  classes  of  types.  There  Is  one  form  declaration  for  each  base  type.  Identifiers 
declared  In  form  declarations  have  normal  Algol  scope. 

5.9.1  Syntax 


‘form  decl> 

‘form  body* 

‘specs* 

<impl> 

‘other  form  decl*» 
«*hered> 

< axiom* 


<»u*>  form  <identifier>(‘tormals>}*  ‘praXassumes*  ij.  ‘form  body* 

I«specs»)*;‘impl>)*  gn£  {‘identifier*}*  | ‘abbrav  body*  | forward  | external 

l ‘system  specs*)  I u specified  4 

scecs  { <var  decl*  I ‘other  form  decls*  ); 

impl  { ‘shared*  <var  decl*  I ‘other  form  decls*  }; 

‘routine  decl*  I ‘form  decl*  | <axiom»|  ‘shared*  ‘const  decl* 
shared* 

invariant  ‘assertion*  | initially  ‘assertion*  | axiom  ‘assertion*  | reamao 
‘assertion*  | rule  <identifier»  ‘assertion* 


6.9.2  Examples 

form  F(T:form.  x:int)  is 
specs 

var  miintj 

vproc  p(f:F):T  pre  {m<x}  post  {m>x};  ... 

Impl 

const  x:as  specified 
var  m:as  specified; 
vproc  p Is  F.m:*F.x*1;  ... 

end 

5.9.3  Semantics 

The ‘names  defined  in  the  specifications  (<specs>)  of  a form  are  available  outside  the  form 
declaration.  The  scope  of  these  names  is  the  same  as  if  they  had  been  declared  immediately  outside 
the  form,  except  that  var  and  const  declarations  become  routine  declarations  as  described  below.  The 
scope  of  the  names  in  the  specifications  does  not  include  the  implementation  (<lmpl>).  Note,  however, 
that  all  these  names  must  be  redeclared  in  the  implementation.  The  Implementation  may  be  omitted  If 
the  form  declaration  appears  as  part  of  the  specifications  of  another  form.  The  specification  may  be 
omitted  if  the  declaration  appears  in  the  implementation  of  another  form,  in  which  case  It  la  copied  from 
the  specifications  of  the  containing  form. 

The  scope  of  object  names  appearing  In  the  formal  parameter  Hat  of  the  form  is  restricted  to  the 
specs  and  <var  decls)  of  the  <form  body)  unless  they  are  explicitly  redeclared  (as  speclfleo)  In  the 
impl.  In  the  latter  case  a run-time  representation  of  these  objects  becomes  part  of  the  implementation 
of  objects  instantiated  from  the  form.  In  such  cases  it  Is  also  possible  for  these  names  to  be  mentioned 
(again  as  specified)  in  the  specs,  and  hence  to  be  externally  available.  These  redeclarations  In  the 
impl  and  specs  must  be  compatible  with  the  <binding>  of  the  formal  parameter;  that  Is,  an  identifier 
redeclared  var  must  also  have  a var  <btndlng>  (an  Identifier  redeciared  const  may  have  a var,  const,  or 
copy  <bindlng>). 

Objects  declared  in  a form  usually  become  the  concrete  components  of  the  objects  that  result  from 
instantiating  the  form;  there  are  thus  distinct  Instantiations  of  these  objects  for  different  instantiations 
of  the  form.  An  exceotion  occurs  when  a declaration  is  prefixed  by  by  the  modifier  shared;  A single 
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instantiation  of  a shared  object  is  common  to  all  instantiations  of  the  form,  in  particular,  It  makes 
perfect  sense  to  define  a shared  const  of  a given  type  within  the  definition  of  that  type.  Such  e 
constant  functions  as  a named  literal  of  the  type. 

<Axiom>s  have  no  semantic  effect,  but  provide  further  specifications. 

Non-shared  constant  and  variable  declarations  within  form  specifications  are  shorthand  for  certain 
procedure  and  selector  declarations.  That  Is, 
form  T... 
specs... 
var  P-.Q 
const  A:R 
is  short  for 

form  T... 
specs... 
sel  P(var  t:T):Q 
func  A(t:T):R 

In  the  implementation,  object  declarations  again  become  selector  and  procedure  declarations  as 
follows.  When  an  object  of  base  type  T is  Instantiated,  the  object  declarations  in  its  Implementation 
are  elaborated  as  usual  (and  the  init  clauses  are  performed).  This  results  in  a set  of  newly  created 
objects  which  become  the  concrete  components  of  the  object  being  created.  These  components  may 
be  accessed  within  the  bodies  of  the  routines  in  the  implementation  by  using  Implicit  selectors 
(procedures)  with  the  same  names  as  those  given  in  the  object  declarations.  Thus,  we  can  write 
form  T... 
impl 

var  x:int; 

proc  f(Q:T)  is  ...  Q.x  ... 

That  is,  inside  f,  "x"  is  treated  as  a selector  on  objects  of  type  T and  is  applied  to  the  formal 
parameter,  Q,  to  access  the  x-component  of  the  particular  actual.  Note  In  particular  that  "x",  Ilka  ell 
object  names,  obeys  restricted  Algol  scope  and  hence  is  not  inherited  by  the  body  of  the  proc,  f. 


5.10.  Abbreviations 

Abbreviated  form  body  definitions  are  provided  for  two  commonly  occurring  kinds  of  abstractions, 
"records'*  and  ordered  "enumerated"  types. 

8.10.1  Syntax 

"ebbrev  body*  "record  type*  I Enumerated  type* 

"record  type*  record  (l<obi  decl  troup>l. ) 

"enumerated  type*  enumerated  ( "identifier  list*  ) 


8.10.2  Examples 

record  (re.im:real) 

record  (x.ynnt.  load  real.  thetarradians) 
enumerated  ( red,  blue,  green,  purple,  bardot  ) 
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5.10.3  Semantics 


The  declaration 

form  F(...)  is  record  (dj^ dk) 

ia  semantically  equivalent  to 
form  F(...)  is 
specs 


var  d , 


func  cons(d^ dk):  F(...)t 

func  &*(lhs.rhS:F):  boolean; 
vproc  &:«(var  Ihs.rhs.F):  F(...); 

Impl 

var  df , ....  dk; 
func  cons  is 

value  v:F(...) 

of  note  assign  to  components  of  v eton  fo 
func  &«  is  note  compare  components  for  equality  eton 
voroc  &:«  is  note  assign  rtis  to  lha  component-bycomponent  eton 
end  F 

In  addition,  all  parameters  of  F are  converted  to  ^Identifiers”  when  they  appear  in  formal  parameter 
lists  of  "cons”,  or 


The  declaration 

form  C is  enumerated  (ij I„) 

is  semantically  equivalent  to 
form  C is 
specs 

shared  const  i^,  ln:C; 
func  4«  ...; 


vproc  ...; 
func  min  ...; 
func  max  ...; 
func  SUCC  ...; 
func  pred  ...; 
func  card  ...; 
func  decode 
func  code  ...; 
func  sped  ...; 
func  unspell  ...; 
generator  gen  ...; 
end  C 


! distinct  constants; 

! equality  test 
! assignment 
I minimum  element  (sl^ ) 

! maximum  element  (»ln) 

! successor  (not  defined  on  ln) 

! predecessor  (not  defined  on  lj ) 

! cardinality  of  enumeration  («n) 

! converts  element  to  Its  ordinal  (e.g.,  decode(l3>3) 
t converts  ordinal  to  element  (e.g..  code(2)*l2) 

I convert  element  to  strtnglet  (Its  printname) 

! convert  strlnglet  (printname)  to  element 
I generates  elements  in  order  (i^  ...  in) 


6.11.  Generators 

Generators  are  specialized  forms.  They  are  useful  for  defining  objects  that  will  be  bound  to  the 
control  variables  of  the  for  and  first  constructs  (see  4.7.  4.5).  (Any  form  may  provide  such  objecta, 
but  their  use  is  sufficiently  constrained  by  the  language  that  special  abbreviated  syntax  ia  provided 
for  defining  forms  intended  specifically  for  this  purpose.) 
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a.  11.1  Syntax 

<torm  decl*  <aux>  generator  identifier*  {<formals>}*  : <type  description*  <pre>  <as*umes* 

ii  <form  body* 


5. 11.2  Example 

generator  upto(lb,ub:int):  Int  Is 
specs 

pro  {ubSmaxint-1  A IbSminint) 
aux  var  k:int*ub*1 ; 
rule  for 

{premise  ISk<u  A l([l..k-1])  {ST(k)>  l([l..k]) 
concl  l([])  {for  k from  g:  upto(l,u)  do  5T(k)  od)  l([l..u])} 
rule  first 

{premise  P A l<kSu  A (Yw)(l<w<k  3 -#(w))  A fl(k)  (S1(k)}  Q 
premise  P A (Yw)(lSw<u  3 -/ !i(w ) { S2 } Q 

concl  P {first  k from  g:  uptoO.u)  suchthat  #(k)  then  SI  (k)  else  S2  ft}  Q) 

impl 

var  k:  as  specified; 
const  Ib.up:  as  specified; 
func  Adone  is  g.k>g.ub; 
sei  Avalue  is  g.k; 
proc  Astart  Is  g.k:«g.lb; 
proc  Anext  is  g.k-*:«1 ; 
proc  Aflnish  is  g.k:ag.ub*1 ; 
endof  upto 

Note  that  in  this  example  we  have  chosen  to  ignore  statement  end  predicate  parameters  other  then  k. 

5. 11.3  Semantics 

In  order  to  generate  loop  control  variables,  a form  must  provide  definitions  for  the  routines  Astart, 
&next,  3. clone  and  3, value.  A definition  of  the  routine  Afinish  is  optional.  If  no  definition  is  provided  for 
& finish,  the  compiler  will  provide  (1)  an  appropriate  header,  (2)  the  body  skip  In  the  specifications,  and 
(3)  the  body  as  specified  in  the  implementation.  Restrictions  on  the  definitions  of  Adone,  Astart, 
Anext,  A finish,  and  Avalue  are  provided  in  appendix  C. 

A distinguished  class  of  forms  defining  objects  for  controlling  loops  is  designated  by  the  reserved 
word  generator  and  the  syntax  indicated  above.  This  class  is  significant  because  the  behavior  of  these 
objects  is  sufficiently  constrained  to  be  specified  by  a proof  rule.  Necessary  properties  of  the 
specifications  of  the  generator  routines  can  ba  derived  from  the  proof  rules  and  the  constraints1^  . As 
a result,  these  specifications  are  not  written  axplicitly.  Instead,  proof  rules  for  first  and  for  loops  that 
use  the  generator  are  written  as  shown  above.  An  Instantiation  of  a generator  may  be  used  only  to 
control  loop  constructs  for  which  it  provides  proof  rules. 


See  "Abstraction  and  Varifieation  in  Alphard:  Oefinmg  and  Specifying  Iteration  and  Generators"  by  Mary  Shaw, 
Wm.  A.  Wulf,  and  Ralph  L London,  in  Commwueatioiu  of  the  ACM,  August  1977,  pp.  553-56 A. 
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Assumptions  provide  "skeleton''  declarations  tor  generic  parameters  and  provide  sufficient 
Information  to  verify  all  uses  of  these  parameters  k>call.y 

6.12.1  Syntax 

<assumes>  (resumes  <form  dacl>)* 


5.12.2  Examples 

assumes  form  T is  specs  func  &*(a,b:T):booiean  ... 

6.12.3  Semantics 

Assumed  forms  may  not  be  parameterized  and  may  not  have  implementations.  Identifiers  appearing  in 
the  update  sets  of  generic  parameters  must  be  specified  In  an  assumes  clause  (see  3.6).  Actual 
parameters  corresponding  to  generic  formats  must  syntactically  satisfy  the  assumptions  about  the 
formal  (see  2.4). 

The  following  routine  illustrates  the  use  of  assumptions  and  generic  parameters: 
func  equai'vectors( x.y: vector! ?T,?lb,?ub)):boolean 
assumes  form  T is  specs  func  &«(a,b:T):boolean  end 
Is  first  I from  upto(lb,ub)  suchthat  x(i]»fy[i]  then  false  else  true  fl 
This  routine  will  determine  whether  two  vectors,  x and  y,  are  equal  so  long  as  (1)  the  type  of  the 
elements  of  the  vectors.  T,  provides  an  equality  operator  and  (2)  the  two  vectors  have  the  same  upper 
and  lower  bounds.  An  assumes  declaration  behaves  as  though  It  had  normal  Algol  scope;  in  particular, 
assumptions  about  generic  parameters  of  a form  need  not  be  repeated  within  routines  (or  other  forms) 
declared  within  the  form.  ~ 
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"lett  er* 

"digit* 

"alphanumeric* 
"special  symbol* 
<basic  symbol* 


"operator* 

<tinary  oparalo r> 

<unary  oparalor> 

"identifier* 
"special  identifier* 
<identifier  li*t> 

<special  literal* 
"unsigned  integer* 
"unsigned  real* 
<unsigned  rational* 
"scale-factor* 
<»tring> 

"boolean* 

"radix* 

"compilation  unit* 
<bloeK> 

"exec  decl  list* 
<exee  decl* 

"expression* 

"stmt* 

<labeled  stmt* 

invocation* 

< actuals* 

< actual* 

"simple  invocation* 


Appendix  A 
Collected  Syntax 

A | S |...|  2 | a |... | i 
0 I 1 | ...  | 9 
<letter>  | <digit>  | ' 

<basic  symbol*  | <operator* 

feEKin  I tnSL  I *"dof  I i I : I ( I ) I I | , I ::  | A | 
if  | thgn  | gist  | fi  | case  I 

at  I «»«  I !fi  I with  | in  I ni  I firgl  | suchthat  | from  | gg  | | 

f2r  | exitloop  t leave  | skip  | assert  | 

var  | cgr*St  I 4Si»  | as  specified  I - I mil  | 

final  | ynx  I 1 I proc  I vproc  I 'unc  | igl  I laoel  | 

note  I eton  | ! | glil  | g!2l  | pform  | while  | * | < I . I a | 

copy  | alias  I form  | inline  | gli  I post  I m!g  | 

!1  I forward  I external  | specs  I imfii.  | shared  | 
invariant  | initially  | axiom  | repmao  | 
r»cord  I enumerated  | assumes  I value  I generator 
<bmary  operator*  | <unary  operator* 

T I * I / | div  I rgm  |»|-|<|S|«|<»|i|»|  jng  | 2L  I cand  | £21. 1 imfi  I 
<assign  op* 

♦ I * I noi 

<letter»  {<alphanumeric>}* 

Astart  | Afimsh  | 4 next  | 4 done  | lvalue  | Asubseript  | A "Operator* 
identifier*, 

"unsigned  integer*  | "unsigned  real*  | "string*  | "boolean*  | "radix* 
{"digit*)* 

"unsigned  rational*{E"scale-lactor>}*  | "unsigned  intsgsr>£"sc  ale -factor* 
"unsigned  integer».«unsigned  integer* 

{*|-}*<unsigned  integer* 

'"any  sequence  of  characters  with  all  quotes  ooubled*' 
true  | false 

{<alphanumeric*)**<alphanunieric> 

beam  "block*  gn£  | "exec  decl  list* 

{"exec  decl  list*?)*  {"stmt*)*  {i}* 

{ "exec  decl*  }t 

"var  decl*  | "const  decl*  | "proc  decl*  | "form  decl*  | "label  decl* 

"invocation*  | "conditional  expression*  | "value  expression*  | 

"with  expression*  ) "first  expression* 

"expression*  | "loop  stmt*  | "exit  stmt*  | "null  stmt*  | 

"inner  block*  | "labeled  stmt*  | "assert  stmt* 

"identifier*  : "stmt* 

"special  literal*  | "simple  invocation»{"actuais»)*  | (invocation*) 
({"actual*),*) 

"expression*  | "type  description* 

("identifier**  J*  "identifier*  | "special  identifier* 


An  Informal  Definition  of  Alphard 


4 i 


Conditional  expression*  <i(  expression*  | <cm  expression* 

<if  expression*  it  expression*  Jhjn  ‘block*  { jlif  expression*  Uaa  Clock*  }•  (else  ‘block*}*  « 

•<€«••  oxprossion*  ;j;»  expression*  jf  ‘case*  { glof  <e«a>  }•  { gin.  <bloek>  }•  MK 

■*«•»•»  {expression*},  ::  ‘block* 


<valua  expression*  value  <idantitiaf»{r<obj  type*}*  dock*  (a 


‘with  expression* 
‘with  li*t> 


with  <with  li»t>  ifj  dock*  ni 
{ ‘identifier*r<invoc*tion>  J, 


<tir»t  expression*  firstiemplata*  suchthst  expression*  tlhandock*)*  lal«a  dock*)*  fj 

<tamplata>  ‘identifier*  trow  {odanti(iar»:)“<typa  description*  | <idantitiar>  from  invocation* 


<>000  stmt* 
‘simple  loop* 
<whila  stmt* 
«for  stmt* 


<timpla  loop*  | ‘while  stmt*  | <for  stmt* 
Si  dock*  25. 

whila  expression*  <sjmpla  loop* 
ter  <tamp)ata*  ‘simple  loop* 


‘exit  stmt* 


exitlpop  | leave  identifier* 


‘null  stmt* 


Skip 


<mnor  block* 


SM-n  <block»  125  | baaw  dock*  andot  {identifier >i* 


<ass#rt  stmt* 


Kiaft  <assartion> 


<iabal  dacl* 


Isbal  ‘identifier  list* 


<v»r  dec'* 
const  dacl* 
<au*> 

<oo  i dacl  grouo* 
<ob(  typa* 

<mit  fin  clausa* 
const  assign* 


<«ux*  v*r  ;<ob.  jrnijp»;<init  tin  clause*)*),* 

<au*»  const  (cb|  dacl  group*  (unit  fin  clausa*}*  | const  assign*},*' 

{no}* 

identifier  list*  : <obf  typa* 

‘type  description*  ) gg  specified 
- expression*  | {ifj5‘stmf>}*  ifinal  <stmt»}* 

‘identifier  list*  • expression* 


<typa  description* 
<tormat  dual* 
<updato  sat* 


Cimple  invocation*  { ( (<formal  dual*},*  ) }*  (<updata  set*}*  | 

?<identifier>{<update  el*}* 

‘expression*  | ?<identifier>{<update  set*}*  | (idantifiar*:}*  <typa  description*  | 
unk 

< [ idantifiar*  | ‘special  idantifiar*  },*  » 


‘formats* 
‘routine  formal* 
‘binding* 
‘formal  id  list* 
‘obj  formal* 
‘typa  formal* 


( (‘routine  formal*  | dnding*<obj  formal*  | <typa  formal*},*  ) 

‘formal  id  list*  a£2£.  ‘perms*  | ‘formal  id  list*  Ivoroe  | fjfljg  | sel)‘v  parms* 
{ COPV  I ( gligg}*(  const  i si r}  }* 
idantifiar  list*  : 

‘forms!  id  list*  ‘type  description* 

‘formal  id  list*  ( form  | aterm  )(<updsta  sat*}* 
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‘routine  decl* 
<vproe  decl* 

‘proc  decl* 

‘sel  decl* 
‘routine  id* 

‘par  ms* 

<v  parms* 

<pr»» 

‘pre  post* 
‘routine  body> 

‘form  decl* 

‘form  body* 

‘specs* 

<impl> 

‘other  form  decls* 
‘shared* 

‘axiom* 


‘abbrev  body> 
‘record  type* 

‘enu mereted  type* 

<form  decl* 


<»sumti> 


<vproc  decl*  | <proc  decl*  | <sal  decl* 

<»u»>  (inlinft)*  karat  | fie£}‘routine  id>  <v  psrms*  <pre  po,t>  ‘assumes* 

(‘routine  body*)*  - 

<»ux»  firlma)*  ero£  ‘routine  id*  ‘parms*  <prp  post*  <Mtumat*  {‘routine  body*}* 

isi<r0utin«  idxv  parms*  <pre  post*  ‘assumes*  {‘routine  body*}* 
‘identifier*  | ‘special  identifier*  1 1 

{‘formal**}* 

(<formal**}*r<typ#  description* 

(pro  ‘assertion*;}* 

*pro>  fpost  ‘assertion*;}* 

!i<stmt»  | iauaaa^  I | i*  12i2rnai  <‘,y,tem  sP.cs» 


<»ux»  form  ‘identifier*(‘formals>}*  <prex*ssumas*  i*  <form  body* 

(‘specs»}*(‘impl>}*  en<J  {‘identifier*}*  | ‘abbrev  body*  I forward  I external 

(<sy*tem  specs*)  | as  specified  “ — 15 

sfiSSi  { <vtr  decl*  | <other  form  decls*  };* 

!2El  I <shared>  <var  dad*  | <other  form  decls*  }* 

‘routine  decl*  | <form  decl*  j <axiom>|  <sh*red>  <const  decl* 
shared* 

invariant  <„s.rt,on>  | iril.ally  <ass,rf,on>  | ‘assertion*  | repmap 

‘assertion*  | rule  ‘identifier*  ‘assertion*  * 


‘record  type*  | ‘enumerated  type* 
r*ddrd  ({<obj  decl  group*}*) 
enumerated  ( ‘identifier  list*  ) 

<*ux>  mar, tar  ‘identifier*  {‘formels*)*  : ‘type  description*  ‘pre*  ‘assumes* 
a ‘form  body* 

[assumes  ‘form  dec!*},* 
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Appendix  B 
Standard  Prelude 

The  complete  specifications  of  the  types  In  the  standard  prelude  will  appear  In  a future  technical 
report.  This  appendix  previews  that  report  by  listing  the  types  to  be  Included  and  summarizing  their 
main  properties.  This,  together  with  the  reader's  experience  and  goodwill,  should  suffice  to  understand 
the  language  definition. 

The  type  definitions  loosely  referred  to  as  the  "standard  prelude"  actually  comprise  three  classes  of 
definitions.  The  primitive  prelude  defines  operationally  the  basic  nation  of  linear  contiguous  storage 
and  all  of  the  common  machine  operations.  The  standard  prelude  proper  includes  types  that  we 
expect  to  be  Implemented  for  all  versions  of  the  language,  usually  as  a part  of  the  compiler.  The 
Implementation  prelude  includes  types  that  provide  facilities  of  the  underlying  hardware,  operating 
system,  or  support  environment  of  a particular  Implamentation.  In  addition,  types  (such  as  reel)  which 
should  be  defined  for  a large  class  of  systems  (but  not  all)  are  defined  here.  It  Is  our  Intention  that 
whenever  a particular  implemantatlon  chooses  to  define  a type  given  here,  it  follows  our  specifications 
to  the  greetest  extent  possible. 


B.1 . Primitive  Prelude 

The  RawStorage  form  supplies  the  fundamental  abstraction  of  linear  contiguous  storage  as 
described  in  Chapter  1 . Fetching  and  storing  are  defined  for  RawStorage  objects  of  equal  length.  The 
Integer  and  bitwise  boolean  operations  are  provided  for  RawStorage  objects  of  length  one.  In  addition 
we  provide  support  here  for  the  subsequent  definition  of  forms  such  as  collections  and  references,  as 
well  as  tha  ability  to  do  storage  management. 


B.2.  Standard  Prelude 

These  types  were  chosen  for  their  simplicity  and  common  utility.  They  are  intended  to  provide  only 
primitive  facilities  that  may  reasonably  be  expected  to  appear  (and  be  efficiently  impiementable)  on  all 
systems.  The  reader  must  bear  in  mind  that  these  specifications  were  selected  with  the  understanding 
that  they  become  essentially  required  of  all  implamantatlons.  When  In  doubt,  therefore,  we  have 
tended  to  exclude  features  rather  than  to  include  them. 

There  are  three  major  classes  of  types  In  the  standard  prelude.  The  sections  below  sketch  the 
major  properties  of  each. 

B.2.1  Scalars 

The  scalar  types  of  the  standard  prelude  are  Boolean  and  Integer.  Literals  of  these  types  are 
defined  in  section  3.5. 

Boolean  Is  the  other  form  required  by  the  language  definition  (Chapter  1).  Objects  of  type  Boolean 
are  unstructured;  they  possess  values  from  a sat  designated  (true,  falaa).  The  customary  unary  and 
binary  functions  are  provided,  along  with  assignment. 
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Integers  ere  restricted  to  machine  precision.  The  standard  prelude  supports  the  customary  unary 
and  binary  arithmetic  operators  on  Integers,  the  arithmetic  relations,  named  constants  to  describe  the 
finite  range  of  a particular  Implementation,  assignment,  and  transfer  functions  to  and  from  Strlngleta. 

B.2.2  Linear  Structures 

Two  linear,  homogeneous,  fixed-length  data  structures  are  provided  in  the  standard  prelude. 
Sectors  may  have  elements  of  many  types;  Strlngleta  are  minimally  sufficient  to  support  I/O 
operations. 

Vectors  may  have  elements  of  almost  any  type  (the  type  must  be  allocatable  without  special 
restrictions).  Any  particular  Vector,  of  course,  contains  elements  of  only  one  type.  The  length  of  a 
Vector  is  fixed  at  instantiation  time.  A subscript  selector  for  integer  Indices  and  a generator  that 
produces  the  elements  in  order  are  provided.  If  the  element  type  supports  either  assignment  or 
equality  test,  that  operation  is  extended  to  the  entire  Vector.  There  is  a slice  routine  which  returns  a 
subvector  of  the  original  vector  (with  the  new  origin  forced  to  zero). 

Strlngleta  closely  resemble  vectors  of  characters.  The  same  operations  are  provided  for  Strlngleta 
as  for  Sectors.  In  addition,  literals  are  supported  by  the  syntax  of  section  3.5  and  an  assortment  of 
special  predicates  on  Strlngleta  of  length  1 is  provided  (IsCharacter,  IsLetter,  IsOlgit.  etc.).  Transfer 
functions  to  and  from  Integers  are  also  provided.  Note  that  type  "character*  la  not  Included  In  the 
standard  prelude;  use  Strlngleta  of  length  1 instead. 


B.3.  Implementation  Prelude 

Certain  other  types  appear  In  some  fashion  in  almost  avery  language.  These  types  do  not  have 
uniform  specifications  across  implementations,  but  rather  depend  on  the  host  machine.  Since  we  don't 
want  to  require  these  for  all  systems,  we  cannot  include  them  in  the  standard  prelude.  Instead,  such 
types  are  provided  in  an  Implementation  prelude  — a segment  of  the  definition  of  each  Implementation 
that  Is  frankly  machine-dependent.  In  addition,  certain  types  which  may  not  exist  under  all 
Implementations,  but  which  must  have  uniform  specifications  for  those  systems  on  which  they  do  exist, 
are  included  here. 

The  types  defined  here  may  provide  direct  access  to  features  of  the  underlying  hardware;  they  may 
support  special  facilities  of  the  environment  or  the  operating  system;  they  may  simply  be  data  typea 
that  are  best  supported  directly  by  the  compiler. 

B.3.1  Scalers 

Reals  have  the  properties  of  hardware  floating-point  values.  Unary  and  binary  arithmetic  operators 
and  relations  are  supported  to  the  extent  that  the  underlying  machine  allows.  Constants  describing 
floating  point  accuracy,  assignment,  and  transfer  functions  to  and  from  Integers  and  Strlngleta  are 
also  provided.  There  is  NO  mixed-mode  arithmetic. 
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B.3.2  Input  and  Output 

The  implementation  prelude  requires  a minimal  sot  of  operations  on  files  of  characters.  This,  together 
with  transfer  functions  to  and  from  Strlnglmt s.  Is  intended  to  guarantee  the  availability  of  at  least 
primitive  Input/output  facilities.  It  Is  Intended  that  each  Implementation  prelude  provide  such  richer 
support  as  is  appropriate,  provided  such  support  is  an  upward  compatible  extension  of  the  facilities 
described  here. 

lOFIIm  supports  sequential  files  of  characters.  Films  are  sequences  of  strlnglmts  of  length 
one.  They  are  constructed  by  appending  Strlnglmts  and  decomposed  into  Strlnglmts.  The  available 
operations  are  commands  to  open  or  close  an  Film  lor  reading  or  writing,  to  test  the  status  of  an  Film, 
and  to  read  or  write  a Strlnglmt  from  or  to  an  Film.  Note  that  Film  is  an  auxiitiary  form  definition— such 
objects  cannot  be  declared.  lOFIIm,  on  the  other  hand,  has  a null  representation.  Hence  It  is  not 
meaningful  to  declare  objects  of  this  type. 

B.3.3  Machine  Dependent  Types 

These  types  may  provide  direct  access  to  features  of  the  underlying  hardware  or  to  special  facilities 
of  the  environment  or  the  operating  system. 
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Appandlx  C 

Spaeial  Idantlfiar  Assumptions 

A certain  number  of  Alphard  routines  are  used  for  special  purposes.  Their  definitions  are  thus  more 
constrained  than  has  been  Indicated  elsewhere  In  this  report.  These  routines  are  distinguished  In  that 
their  names  begin  with  ampersand  ("A");  syntactically,  they  are  (special  Identifiers.  The  routines  are 
invoked  by  specific  language  constructs  rather  than  by  ordinary  routine  invocation. 

These  routines  are  grouped  into  two  classes.  Generator  routlnas  are  Invoked  by  the  for  and  first 
iteration  constructs  in  the  manner  described  In  sections  4.7  and  4.8.  ExtansJbla  oparators  are 
affected  by  the  Infix  operator  rewrite  rules  as  well  as  by  the  subscript  rewrite  rule  (see  section  3.4). 
Extensible  operators  include  all  operators  named  by  (special  identifiers  other  than  generator  routines; 
they  can  be  overloaded  by  user-defined  forms. 


C.l.  Generator  routines 

The  generator  routines  are  Adone,  Aatart.  Anext,  iflmsh  and  lvalue. 

C.1.1  Use  restrictions 

The  restrictions  on  the  invocation  of  generator  routines  as  an  ordinary  routines  are  intended  to 
support  two  conflicting  requirements.  First,  it  is  mandatory  that  a for  or  first  loop  body  not  be  able  to 
use  these  functions  on  the  object  generating  the  loop  control  variable,  it  is.  In  general,  desirable  that 
they  not  be  invoked  in  other  arbitrary  places  outside  of  loops  either.  It  Is,  however,  useful  to  be  able 
to  use  these  routines  in  the  definitions  of  other  generators,  specifically  those  which  simultaneously 
generate  elements  of  two  or  more  data  structures. 

The  invocation  restriction  Is  thus  that:  Astart,  Anext  and  1 finish  can  only  be  Invoked  in  the  definition 
of  an  istart,  Anext  or  & finish  routine  of  another  generator;  Adone  can  only  be  invoked  in  the  definition 
of  an  istart.  inext,  iflnlsh  or  Adone  routine  in  another  generator;  Avaiue  can  only  be  Invoked  within 
another  generator.  This  would  seem  to  permit  use  of  the  same  generator  object  to  create  control 
variables  In  two  nested  loops.  Any  problems  which  this  might  cause  for  the  generator  object  would  be 
detected  as  violations  of  sufficient  independence  of  the  object  from  the  body  of  the  outer  loop. 

C.l. 2 Definition  restrictions 

Suppose  a generator  named  gen  defines  a type  of  object  that  provides  a control  variable  of  type  t 
for  the  "(Identifier)  from"  construct.  The  generator  routines  must  have  header  specif Icationa 
subsuming; 

func  Adone(g:gen):booi; 
sel  Avatue(g:gen):t; 
proc  Astart(g:gen); 
proc  Anext(g:gen); 
proc  Afinish(g:gen); 
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C.2.  Extansibla  routines 

The  extensible  routines  are  &«,  &*,  &/,  *<div,  &rem,  &+(unary  and  binary),  &-(unary  and  binary),  &<, 
5.*,  &>,  3>and,  &or,  Simp,  &not,  &:■  and  &aubscrtpt. 

C.2.1  Use  restrictions 

Extensible  routines  can  be  Invoked  either  by  using  the  Infix  operator  rewrite  rule  or  by  using  the 
subscript  rewrite  rule  (see  3.4).  There  is  no  loss  of  generality  in  prohibiting  their  Invocation  as  ordinary 
routines. 

C.2.2  Definition  restrictions 

Within  form  f,  specifications  of  these  operators  must  subsume: 
func  &>(leftparm:f,rightparm:t):t1; 
func  &’(leftparm,rfghtparm:f):f; 
func  &/(leftparm,rightparm:f):f; 
func  &dlv(leftparm,rlghtparm:f):t; 
func  &rem(laftparm,rfghtparm:f):t; 
func  &*<leftparm,rightparm:f):f; 
func  3r»(parsi:f):f; 
func  &-(leftparm,rightparm:f):f; 
func  &-(parm:f):f; 
func  &<(leftparm.rightparm:f):boo!; 
func  &a(leftparm,rightparm:f):booi; 
func  &>(leftparm,rtghtparm:f):boot; 
vproc  &:»( alias  var  leftparm:f,  alias  rightparm:f):f; 
sal  &subscript(afCerdot:f.p1:t1,  ..  ,pn:tn):t; 

The  compiler  is  able  to  enforce  only  the  precedence  and  syntax  of  these  operators.  However,  their 
traditional  use  in  mathematics  raises  other  expectations  about  them;  most  people,  for  example, 
presume  is  at  least  associative  and  possibly  commutative.  We  strongly  urge  that  the  programmer 
overload  these  operators  only  with  operations  that  preserve  those  expectations;  failure  to  observe 
this  convention  may  badly  mislead  the  reader. 
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Appendix  D 
A Complete  Example 


We  now  present  a complete  Alphard  program.  This  program  defines  finite  sets  with  a fixed  maximum 
size,  then  uses  them  in  a small  program.  Several  aspects  of  the  program  deserve  special  note. 


Form  FinSet  defines  one  variety  of  sets.  These  sets  must  be  homogeneous  (l.e.,  all  elements  must  be 
of  the  same  type),  but  the  elements  may  be  of  any  type  that  providas  assignment  and  equality 
operators.  Thus  FinSet  Is  a generic  type  definition.  The  specifications  of  FinSet  are  stated  In  terms  of 
ordinary  mathematical  sets;  the  restrictions  that  apply  to  sets  of  type  FinSet  are  explicit. 

We  assume  the  types  of  the  standard  preluda.  Appendix  B.  In  particular,  we  use  vectors,  integers, 
and  the  generator  upto  for  integers.  The  main  program  defines  an  ordered  enumerated  type  and  uses 
the  generator  that  is  automatically  defined  for  such  a type. 

The  names  V and  m used  in  the  implementation  of  FinSat  are  available  to  the  bodies  of  the  routines 
defined  in  that  form.  V and  m may  be  used  as  qualifiers  on  any  objects  of  type  FinSet  that  those 
routines  receive  as  parameters.  The  names  V and  m are  not  available  outside  the  form. 

FinSet  defines  routines  &+(union),  &*(lntersect),  &:*(assign),  and  &«(equality).  These  extend  the 
definitions  of  the  binary  infix  operators  ♦,  *,  and  ■ to  pairs  of  FinSats.  The  FinSet  Implementation 
also  takes  advantage  of  the  rewrtte  rule  for  ♦-.«  and 


Assertions  are  included  in  the  specifications  of  the  FinSet  operators.  (We  use  "prime*  notation  in 
post  conditions:  S'  is  the  value  that  S had  on  entry  to  the  procedure.)  Some  have  also  been  Included  In 
the  main  program  to  explain  the  operation  of  the  program. 

Three  kinds  of  loops  are  used.  Routines  Insert,  Remove,  and  Has  all  use  first  loopa  to  search  for 
elements.  Insert  defaults  the  then  part  and  Remove  defaults  the  else  part.  Note  that  the  equality  test 
in  the  suchthat  clauses  of  these  loops  uses  the  equality  defined  for  EltType.  As  a result,  the  code  for 
these  routines  may  depend  on  the  definition  of  the  type  passed  as  an  instantiation  parameter  to 
FinSet.  The  main  program  declares  three  sets  — one  is  a set  of  colors  and  the  other  two  are  sets  of 
sets  (of  colors).  The  program  uses  for  loops  with  the  generator  cotorjgan  on  colors.  It  also  uses  a 
conventional  while. 

The  'S'  name  qualification  is  used  for  names  coiorScard  and  color$gen.  These  are  constants  defined 
for  the  ordered  enumerated  type  color  (number  of  elements  and  a standard  generator,  respectively). 
They  are  associated  with  the  type  rather  than  with  any  variable  of  the  type.  The  qualification  Is  used 
to  distinguish  ord  and  gen  from  the  corresponding  definitions  associated  with  other  enumerated  types. 
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&aain 


form  FinSet  (El  tTuae:  fora<4:--4->.  flaxSize:  integtr) 
ora  I MaxS iza  2 8 I 


I 0 1PQC3 

aux  var  FSsflatheaat  icalSat  (El  tType) 
i nvar  i ant  I cardinal  i tg(FS)  S flaxSize 
initial lu  ( FS- ( I I 
proc  Insertlvar  SiFinSat.xiEl tTuoa) 

proc  flemove(var  Si  Fi nSe t . x: El t Tuoe) 
vproc  Choose(SiFinset) :EI tType 

func  Has(S:FinSet.x:EI  tTypa)  tboolaan 
func  4* (R. S: F inSat ) :F i nset 


ore 

( 

cardinal  i ty(  (x)  U S.FS)  S S. flaxSize  ) 

Post 

( 

S.FS-S.FS'  U Ixl  1 

post 

{ 

S.FS  - S.FS’  - (x!  1 

pre 

1 

S.FS  - 1 1 1 

post 

1 

resul t c S.FS  I 

post 

( 

resul t e xcS.FS  I 

pre 

( 

cardinal  i tytR.FS  U S.FS)  S R.flaxSiza  ) 

post 

( 

result  ■ R.FS'  U S.FS’  1 

post 

( 

result  a R.FS'  n S.FS’  ) 

cost 

( 

result  • R.FS  - S.FS*  ) 

Post 

( 

result  e (R.FS*  ■ S.FS’)  ) 

func  4*(R,S:FinSet) :FinSet 
voroc  4: - (var  R,S:F i nSet ) :F i nSet 
f unc  4- (R. SiFinSe t) : boo  lean 
func  Emp  tySat  (E I- tuoe:  fore.  flaxSize:  integer) iFinSet  (El  type,  flaxSize) 
post  ( r-sul t -II) 


i mp  I 

var  V;  vector  (E I tType,  1, flaxSize) , asintager  ini  t a:-9 
const  flaxSize:  gg  spec '■  f i ad; 
rspwao  ( FS  - IV[iJ  I lsisal  I 

i nvar  i ant  I (BsasflaxSize)  n (Vi , j<  Cl.  .a)  (V  ti ] -V  t jlpi- j) ) I 
proc  Insert 

i s first  p from  upto(l.S.a)  suchthat  S.Vtp]-x 
e I se  S.a  1;  S.V(S.a]>-x  f i 
proc  Remove 

i 3 first  p from  upto(l.S.a)  suchthat  S.Vtpl.x 
then  S.  V (pi : -S.  V (S.aJ  i S.a  1 f i 
vproc  Choose  j_g  S.VIl] 
func  Hae 

i 3 first  p froa  upto(l.S.a)  suchthat  S.VIpl.x 
then  true  else  falsa  fj, 

func  4+ 

i s va I ue  TsFinsat  (R. El  tTypa. R.naxSiza)  gf. 

T.a  i-  R.a 

for  j froa  upto(l.R.a)  gg  T. V £ j J t-  R.VCj]  gg 
for  j froa  upto(l,S.a)gg  I near  t (T.S.  V ( i]  )od 
IS 

func  4«r 

il  va  I ue  TsF  inset  (R. El  tType. R. flaxSize)  gi 

for  j froa  uoto(l.R.a)  gg  if,  Hae(S,R.V(j] ) 
then  InaartIT. R.VCj])  .fi  gg 

is. 

vproc  4: - 

• il  va  (ue  R gi  R.a  s-  S.ai  for  I froa  upto(l.S.a)  gg  R.V(l)  : - S.VIIJ  gg  fg 


5a 
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func  4- 

la  R.»-S.»  jnfl  f irst  i f row  upto(l.R.a)  auchthat  not  HaofS.R.  V ( 1 J ) 
then  falsa  also  true  f i 
func  EmptySet 

la  vQiue  * ai  skip  fo 

end 

! Compute  pouerset  of  anuiaaratad  type 

f Of'11  color  enumerated  (red,  orange,  ye  I lou, green, blue. violet)  and 
vjr  Co  I or  Sat:  F i nSa  t (F  i nSat  (col  or , col  ortcard) , 2fcolortcard) 
asser  t I ColorSat  -III 

I naer  t (Co  I or  Sat  .EmptySet  (F  inSat  (color  .color  (card) ) ) 
asser ; ( ColorSat  *11111 
Lac.  C f rrW  co I or (gen  do 

ver  Tamp:  FlnSet(FinSat(color,color<card),  2tcolortcard) 

Temp  :•  ColorSat 

tflf ' 1 e Tamo  ■ EmptySet  (FinSet  (color  .colortcard)  I do 
vgr,  Current:  F i nSat  (co lor,  col orlcard) 

Remove  (Temp. Current!  -Choose  (Temp) ) 

Insert  (Current,  c)  i Insert  (ColorSat,  Current) 

94 

ad. 

•c*r t * ColorSat  • ( S I S a l*lx  is  a value  of  type  ColorSat)  I ) 
end 


f 
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Appendix  £ 

Proof  Rules 


Proof  Rules  Omitted  Prom  Prellminery  Version 


